ReSQL.ru
     
powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Sybase ASA, ASE, IQ [игнор отключен] [закрыт для гостей] / ASE15.7 непонятная оценка оптимизатора по составному индексу
25 сообщений из 25, страница 1 из 1
ASE15.7 непонятная оценка оптимизатора по составному индексу
    #38552989
Mikle83
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mikle83
Участник
Всем привет!

Сложилась интересная и непонятная пока для меня ситуаций.
Есть таблица T1 ~7.5 млн строк/3.5 млн страниц (pagesize=2k).

Есть индекс Index1:
Код: sql
1.
Create Index Index1 on T1(C1, C2)


leafcnt = 19029; indexheight = 2

есть выборка по типу:

Код: sql
1.
2.
3.
4.
5.
6.
Select top 2500
  C1 
from T1
  where (C1 in (v1,v2,v3,.....,vn))           
           AND 
           (C2 in (v1,v2,v3,v4))



статистика по данным такая:
Код: sql
1.
Select Count(*) from T1 where C1 in (v1,v2,v3,.....,v18)


выдает ~400 000 записей.
Код: sql
1.
Select Count(*) from T1 where C1 in (v1,v2,v3,.....,v18) and C2 in (v1,v2,v3,v4)


выдает около 350 записей.


Что ожидается: выборка должна проходить по индексу Index1 с позиционированием по ключу C1 + C2.
Что дает оптимизатор:

Код: sql
1.
2.
3.
4.
5.
6.
7.
       |   |   |   |   |  Index : Index1
       |   |   |   |   |  Forward Scan.
       |   |   |   |   |  Positioning by key.
       |   |   |   |   |  Keys are:
       |   |   |   |   |    C1 ASC
       |   |   |   |   |  Using I/O Size 16 Kbytes for index leaf pages.
       |   |   |   |   |  With LRU Buffer Replacement Strategy for index leaf pages.



При этом, если объем in для С1 скоратить до 6 значений, позиционирование по двум ключам:
Код: sql
1.
2.
3.
4.
5.
6.
7.
       |   |   |   |  Index : Index1
       |   |   |   |  Forward Scan.
       |   |   |   |  Positioning by key.
       |   |   |   |  Keys are:
       |   |   |   |    C1 ASC
       |   |   |   |    C2 ASC
       |   |   |   |  Using I/O Size 16 Kbytes for index leaf pages.



статистика по индексу и таблице обновлена. Индекс перестраивались неоднократно.

Посмотрел на стоимость - с чего-то резко возрастает
Код: sql
1.
Estimated selectivity for С1


при добавлении 7-го значения...
При 6 значениях selectivity = 0.003155239 , при 7 значениях в in selectivity = 0.01743903
и дальше в принципе не сильно варьируется вплоть до 18 значений.

Вопрос - что могло привести к такому резкому скачку в оценке selectivity?
...
Рейтинг: 0 / 0
07.02.2014, 11:35
| Ответить | Цитировать | Написать  
ASE15.7 непонятная оценка оптимизатора по составному индексу
    #38553075
Mikle83
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mikle83
Участник
после скачка оценки сервер заявил, что ему слишком дорогу два ключа поддержать (с чего - опять же не понимаю).
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
    Estimated selectivity for С1,
        selectivity = 0.01743903,
    Estimated selectivity for С2,
        selectivity = 0.01146049,
    OR predicates after key = 2 too expensive
    recosting scan without expensive predicate(s)
    Estimated selectivity for С1,
        selectivity = 0.01743903,
    scan selectivity 0.01743903, filter selectivity 0.01743903
    special or terms 7
...
Рейтинг: 0 / 0
07.02.2014, 12:15
| Ответить | Цитировать | Написать  
ASE15.7 непонятная оценка оптимизатора по составному индексу
    #38553135
cherrex_Den
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cherrex_Den
Гость
Mikle83,

Покажите
Код: sql
1.
set statistics io on


и полные планы на обеих запросах(с 6 значениями и больше 6)
...
Рейтинг: 0 / 0
07.02.2014, 12:38
| Ответить | Цитировать | Написать  
ASE15.7 непонятная оценка оптимизатора по составному индексу
    #38553194
Mikle83
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mikle83
Участник
cherrex_Den, сорри за портянки, но так нагляднее

для запроса 6 rows of OR/IN values
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
Optimized using Deferred Parallel Mode
    STEP 1
        The type of query is SELECT.
	6 operator(s) under root
       |ROOT:EMIT Operator (VA = 6)
       |
       |   |TOP Operator (VA = 5)
       |   |  Top Limit: 2500
       |   |
       |   |   |NESTED LOOP JOIN Operator (VA = 4) (Join Type: Inner Join)
       |   |   |
       |   |   |   |NESTED LOOP JOIN Operator (VA = 2) (Join Type: Inner Join)
       |   |   |   |
       |   |   |   |   |SCAN Operator (VA = 0)
       |   |   |   |   |  FROM OR List
       |   |   |   |   |  OR List has up to 6 rows of OR/IN values.
       |   |   |   |
       |   |   |   |   |SCAN Operator (VA = 1)
       |   |   |   |   |  FROM OR List
       |   |   |   |   |  OR List has up to 4 rows of OR/IN values.
       |   |   |
       |   |   |   |SCAN Operator (VA = 3)
       |   |   |   |  FROM TABLE
       |   |   |   |  T1
       |   |   |   |  a0
       |   |   |   |  Index : Index1
       |   |   |   |  Forward Scan.
       |   |   |   |  Positioning by key.
       |   |   |   |  Index contains all needed columns. Base table will not be read.
       |   |   |   |  Keys are:
       |   |   |   |    C1 ASC
       |   |   |   |    C2 ASC
       |   |   |   |  Using I/O Size 16 Kbytes for index leaf pages.
       |   |   |   |  With LRU Buffer Replacement Strategy for index leaf pages.

Table: T1 (a0) scan count 24, logical reads: (regular=44 apf=0 total=44), physical reads: (regular=0 apf=0 total=0), apf IOs used=0



для запроса 7 rows of OR/IN values
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
Optimized using Deferred Parallel Mode
    STEP 1
        The type of query is SELECT.

	5 operator(s) under root

       |ROOT:EMIT Operator (VA = 5)
       |
       |   |TOP Operator (VA = 4)
       |   |  Top Limit: 2500
       |   |
       |   |   |NESTED LOOP JOIN Operator (VA = 3) (Join Type: Inner Join)
       |   |   |
       |   |   |   |SCAN Operator (VA = 0)
       |   |   |   |  FROM OR List
       |   |   |   |  OR List has up to 7 rows of OR/IN values.
       |   |   |
       |   |   |   |RESTRICT Operator (VA = 2)(0)(0)(0)(13)(0)
       |   |   |   |
       |   |   |   |   |SCAN Operator (VA = 1)
       |   |   |   |   |  FROM TABLE
       |   |   |   |   |  T1
       |   |   |   |   |  a0
       |   |   |   |   |  Index : Index1
       |   |   |   |   |  Forward Scan.
       |   |   |   |   |  Positioning by key.
       |   |   |   |   |  Index contains all needed columns. Base table will not be read.
       |   |   |   |   |  Keys are:
       |   |   |   |   |    C1 ASC
       |   |   |   |   |  Using I/O Size 16 Kbytes for index leaf pages.
       |   |   |   |   |  With LRU Buffer Replacement Strategy for index leaf pages.

Table: T1 (a0) scan count 7, logical reads: (regular=329 apf=0 total=329), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
...
Рейтинг: 0 / 0
07.02.2014, 13:02
| Ответить | Цитировать | Написать  
ASE15.7 непонятная оценка оптимизатора по составному индексу
    #38553321
cherrex_Den
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cherrex_Den
Гость
Mikle83,

Я так подозреваю, что когда оптимизатор видит мало значений в in, он выбирает стратегию nl join по обеим колонкам, если видит много значений то выбирает nl join по одной колонки, а по второй просто restrict.
Вариант такой:
сдернуть абстрактный план с запроса где 6 значений и подсунуть его запросу с 18 значениями, проверить IO с абстрактным планом и без него, если с планом меньше, то так и оставить!
...
Рейтинг: 0 / 0
07.02.2014, 13:47
| Ответить | Цитировать | Написать  
ASE15.7 непонятная оценка оптимизатора по составному индексу
    #38553425
Mikle83
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mikle83
Участник
Попробую конечно, но в продакшен такое не смогу включить (там довольно сложная схема построения запроса) и это только единичный пример выборки, а могут быть иные условия и явно должен быть другой план
...
Рейтинг: 0 / 0
07.02.2014, 14:19
| Ответить | Цитировать | Написать  
ASE15.7 непонятная оценка оптимизатора по составному индексу
    #38553586
Mikle83
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mikle83
Участник
абстрактрный план с 6 значений имеет явное указание этих 6 значений.
Может быть я что-то не так смотрю?
...
Рейтинг: 0 / 0
07.02.2014, 15:25
| Ответить | Цитировать | Написать  
ASE15.7 непонятная оценка оптимизатора по составному индексу
    #38554276
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Mikle83,

у тебя же при таком раскладе

where (C1 in (v1,v2,v3,.....,vn))
AND
(C2 in (v1,v2,v3,v4))

в результат пропадают все возможные сочетания значений с1 и с2, естественно, что их количество растет очень быстро, а вместе с ним и результирующая селективность.
...
Рейтинг: 0 / 0
08.02.2014, 06:26
| Ответить | Цитировать | Написать  
ASE15.7 непонятная оценка оптимизатора по составному индексу
    #38554278
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
извините, не так написал, селективность как раз падает, число записей по оценке растет...
...
Рейтинг: 0 / 0
08.02.2014, 06:29
| Ответить | Цитировать | Написать  
ASE15.7 непонятная оценка оптимизатора по составному индексу
    #38554736
Mikle83
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mikle83
Участник
MasterZivизвините, не так написал, селективность как раз падает, число записей по оценке растет...
Так оно понятно, что селективность падает, но с какого сервер предпочитает делать скан по одному полю индекса, вместо использования обоих полей? В любом же случае "перебрать" индекс по двум ключам - оно быстрее, нежели выполнять полный скан всего индекса... Вот это для меня не совсем понятно...
...
Рейтинг: 0 / 0
09.02.2014, 00:11
| Ответить | Цитировать | Написать  
ASE15.7 непонятная оценка оптимизатора по составному индексу
    #38554777
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Mikle83MasterZivизвините, не так написал, селективность как раз падает, число записей по оценке растет...
Так оно понятно, что селективность падает, но с какого сервер предпочитает делать скан по одному полю индекса, вместо использования обоих полей? В любом же случае "перебрать" индекс по двум ключам - оно быстрее, нежели выполнять полный скан всего индекса... Вот это для меня не совсем понятно...
по двум -- да, но у тебя-то не два ...

Сколько кстати ? давай посчитаем...
...
Рейтинг: 0 / 0
09.02.2014, 01:50
| Ответить | Цитировать | Написать  
ASE15.7 непонятная оценка оптимизатора по составному индексу
    #38555271
cherrex_Den
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cherrex_Den
Гость
Mikle83 абстрактрный план с 6 значений имеет явное указание этих 6 значений.
Может быть я что-то не так смотрю?

Совсем не туда!
Код: sql
1.
set option  show_abstract_plan  on



Но это не поможет! В AP можно указать какой индекс использовать, а вот заставить его 2 колонки использовать, я что-то не нашел!
...
Рейтинг: 0 / 0
10.02.2014, 09:03
| Ответить | Цитировать | Написать  
ASE15.7 непонятная оценка оптимизатора по составному индексу
    #38555312
Mikle83
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mikle83
Участник
MasterZivMikle83пропущено...

Так оно понятно, что селективность падает, но с какого сервер предпочитает делать скан по одному полю индекса, вместо использования обоих полей? В любом же случае "перебрать" индекс по двум ключам - оно быстрее, нежели выполнять полный скан всего индекса... Вот это для меня не совсем понятно...
по двум -- да, но у тебя-то не два ...

Сколько кстати ? давай посчитаем...

Эм. Индекс создан как раз по двум полям, для которых указаны условия в Select.
И при небольшом объеме IN-a как раз-таки сервер ведет себя ожидаемо:
Код: sql
1.
2.
3.
4.
5.
6.
7.
       |   |   |   |  Index : Index1
       |   |   |   |  Forward Scan.
       |   |   |   |  Positioning by key.
       |   |   |   |  Keys are:
       |   |   |   |    C1 ASC
       |   |   |   |    C2 ASC
       |   |   |   |  Using I/O Size 16 Kbytes for index leaf pages.



но при расширении выборки по С1 - "забывает" про возможность использовать эту связку.
...
Рейтинг: 0 / 0
10.02.2014, 09:55
| Ответить | Цитировать | Написать  
ASE15.7 непонятная оценка оптимизатора по составному индексу
    #38555326
Mikle83
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mikle83
Участник
cherrex_DenНо это не поможет! В AP можно указать какой индекс использовать, а вот заставить его 2 колонки использовать, я что-то не нашел!
Да, действительно в обоих случаях абстрактные планы одинаковы, что несколько странно :(
Все-таки сайбез не дает полностью управлять планами запросов и что-то оставляет на оптимизатор...
...
Рейтинг: 0 / 0
10.02.2014, 10:13
| Ответить | Цитировать | Написать  
ASE15.7 непонятная оценка оптимизатора по составному индексу
    #38555328
Mikle83
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mikle83
Участник
сам абстрактный план:
Код: sql
1.
( i_scan Index1 T1 ) ( prop T1 ( parallel 1 ) ( prefetch 16 ) ( lru ) )
...
Рейтинг: 0 / 0
10.02.2014, 10:16
| Ответить | Цитировать | Написать  
ASE15.7 непонятная оценка оптимизатора по составному индексу
    #38555355
cherrex_Den
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cherrex_Den
Гость
Mikle83,

Я тоже ожидал, что планы будут разные! Но увы....
Можно попробовать переписать запрос, загнать все что в IN во временную таблицу с одним полем.
...
Рейтинг: 0 / 0
10.02.2014, 10:44
| Ответить | Цитировать | Написать  
ASE15.7 непонятная оценка оптимизатора по составному индексу
    #38555400
Mikle83
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mikle83
Участник
cherrex_DenMikle83,
Я тоже ожидал, что планы будут разные! Но увы....
Можно попробовать переписать запрос, загнать все что в IN во временную таблицу с одним полем.
Делал так - просто одно поле - не помогает - индекс используется по одному полю.
Сделал "кросс-таблицу" по обоим полям, т.е. записал в нее все возможные сочетания C1 + C2 и приджойнил - вот тогда сервер использует индекс по полной (оба ключевых поля использует при джойне).

Но сложность ситуации в том, что запрос прилетает с клиентской части, там работает что-то типа конструктора запросов. Т.е. по сути набирается несколько условий и они преобразуются в IN. Заставить их использовать промежуточную таблицу - будет сложно.

Думаю в сторону создания некоторых вычисляемых полей в таблице на основе С1 и С2, которые будут "группировать" значения С1 и С2.
Далее индекс по этим вычисляемым полям. Проверил - на минимальных выборках это помогает.

Сейчас буду пробовать на основной таблице "проделать" это, но пугает перестроение всех индексов в момент создания вычисляемого поля = ресурсоемкий процесс, соотв. отправлю его в ночь.
...
Рейтинг: 0 / 0
10.02.2014, 11:22
| Ответить | Цитировать | Написать  
ASE15.7 непонятная оценка оптимизатора по составному индексу
    #38555555
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Mikle83cherrex_DenНо это не поможет! В AP можно указать какой индекс использовать, а вот заставить его 2 колонки использовать, я что-то не нашел!
Да, действительно в обоих случаях абстрактные планы одинаковы, что несколько странно :(
Все-таки сайбез не дает полностью управлять планами запросов и что-то оставляет на оптимизатор...

Есть абстрактные планы и полные планы. В случае полного плана очень немного остаётся на волю оптимизатора.
...
Рейтинг: 0 / 0
10.02.2014, 12:58
| Ответить | Цитировать | Написать  
ASE15.7 непонятная оценка оптимизатора по составному индексу
    #38555559
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Mikle83,

Я тебе всё же предлагаю:

-- дать полный DLL нужных таблиц
-- дать конкретный полный запрос.
-- дать его план.
-- дать конкретный перечень значений в IN.
...
Рейтинг: 0 / 0
10.02.2014, 13:00
| Ответить | Цитировать | Написать  
ASE15.7 непонятная оценка оптимизатора по составному индексу
    #38555588
Mikle83
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mikle83
Участник
MasterZiv,
к сожалению не смогу выложить DDL боевых таблиц. Но! Эффект воспроизводится на следующем кейсе:

создаем таблицу:
Код: sql
1.
2.
Create table T1
(C1 int Null, C2 int Null, C3 char(100) Null)



заполняем таблицу:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
insert into T1(C1,C2,C3)
select 
  TT.N*10000 + T.N*1000 + H.N*100 + D.N*10 + E.N, H.N*100 + D.N*10 + E.N, 'BIG BIG BIG BIG BIG BIG BIG BIG BIG BIG BIG BIG BIG BIG BIG BIG BIG BIG BIG BIG BIG BIG BIG BIG TEXT'
from #tmp E
    join #tmp D on 1=1
    join #tmp H on 1=1
    join #tmp T on 1=1
    join #tmp TT on 1=1


insert into T1(C1,C2,C3)
select 
  TT.N*10000 + T.N*1000 + H.N*100 + D.N*10 + E.N, H.N*100 + D.N*10 + E.N - DatePart(second, getdate()), 'TEXT'
from #tmp E
    join #tmp D on 1=1
    join #tmp H on 1=1
    join #tmp T on 1=1
    join #tmp TT on 1=1



создаем индекс:
Код: sql
1.
create index Index1 on T1(C1,C2)




и смторим план на выборках со случайными значениями:
Код: sql
1.
2.
3.
Select C1 from T1
where C1 in (69809,85132)
and C2 in (39436)


получаем использование двух ключей С1+С2.

А при более широкой выборке
Код: sql
1.
2.
3.
4.
Select C1 from T1
where C1 in (69809,85132,31781,52323,87467,24347,99568,11243,54472,325,8546,10692,29053,97752,47466,19061,78849,21358,60939,79110,55862,26110,94280,
88809,68352,51910,91711,83793,73189,75001,39816)
and C2 in (39436,30287,7459,25990,40847)


получаем использование только одного ключа С1
...
Рейтинг: 0 / 0
10.02.2014, 13:23
| Ответить | Цитировать | Написать  
ASE15.7 непонятная оценка оптимизатора по составному индексу
    #38555597
Mikle83
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mikle83
Участник
пропустил создание темповой таблицы, но там все тривиально

Код: sql
1.
2.
Select 0 as N into #tmp union Select 1 union Select 2 union Select 3 union Select 4 union Select 5
union Select 6 union Select 7 union Select 8 union Select 9
...
Рейтинг: 0 / 0
10.02.2014, 13:28
| Ответить | Цитировать | Написать  
ASE15.7 непонятная оценка оптимизатора по составному индексу
    #38555728
cherrex_Den
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cherrex_Den
Гость
Mikle83,

Переставьте поля в индексе! Что будет?

Код: sql
1.
create index Index1 on T1(C2,C1)
...
Рейтинг: 0 / 0
10.02.2014, 14:35
| Ответить | Цитировать | Написать  
ASE15.7 непонятная оценка оптимизатора по составному индексу
    #38555875
Mikle83
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mikle83
Участник
cherrex_DenMikle83,

Переставьте поля в индексе! Что будет?

Код: sql
1.
create index Index1 on T1(C2,C1)



Прикольный эффект. Используются оба ключа для поиска...

Нашел весьма занимательную вещь:
если в селекте поставить первую колонку из индекса - сервер выбирает стратегию "одного ключа",
если поставить вторую - то сканит по двум ключам...

Т.е. при индексе (С2,С1)
Код: sql
1.
SELECT C2 ....


выдает
Код: sql
1.
Keys are: C2



если ставлю запрос
Код: sql
1.
SELECT C1 ....

выдает
Код: sql
1.
Keys are: C2 Asc   C1 Asc



загадко однако...
...
Рейтинг: 0 / 0
10.02.2014, 15:56
| Ответить | Цитировать | Написать  
ASE15.7 непонятная оценка оптимизатора по составному индексу
    #38555917
Mikle83
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mikle83
Участник
хотя, при указании первой колонки индекса - не требуется читать все листья индекса, может быть оно и верно, что используется только один ключ, но далеко не прозрачно поведение сервера...
...
Рейтинг: 0 / 0
10.02.2014, 16:17
| Ответить | Цитировать | Написать  
ASE15.7 непонятная оценка оптимизатора по составному индексу
    #38556437
cherrex_Den
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cherrex_Den
Гость
Mikle83,

Наверное мы все таки зря ругаем оптимизатор.
Все на вашем примере.

Код: sql
1.
2.
3.
4.
5.
6.
create index Index1 on #T1(C1,C2)

Select * from #T1
where C1 in (69809,85132,31781,52323,87467,24347,99568,11243,54472,325,8546,10692,29053,97752,47466,19061,78849,21358,60939,79110,55862,26110,94280,
88809,68352,51910,91711,83793,73189,75001,39816)
and C2 in (39436,30287,7459,25990,40847)



|ROOT:EMIT Operator (VA = 4)
|
| |NESTED LOOP JOIN Operator (VA = 3) (Join Type: Inner Join)
| |
| | |SCAN Operator (VA = 0)
| | | FROM OR List
| | | OR List has up to 31 rows of OR/IN values.
| |
| | |RESTRICT Operator (VA = 2)(0)(0)(0)(1)(0)
| | |
| | | |SCAN Operator (VA = 1)
| | | | FROM TABLE
| | | | #T1
| | | | Index : Index1
| | | | Forward Scan.
| | | | Positioning by key.
| | | | Keys are:
| | | | C1 ASC
| | | | Using I/O Size 64 Kbytes for index leaf pages.
| | | | With LRU Buffer Replacement Strategy for index leaf pages.
| | | | Using I/O Size 8 Kbytes for data pages.
| | | | With LRU Buffer Replacement Strategy for data pages.

Table: #T1 scan count 31, logical reads: (regular= 155 apf=0 total= 155 ), physical reads: (regular=0 apf=0 total=0), apf IOs used=0

поменяли поля в индексе
Код: sql
1.
2.
3.
4.
5.
6.
create index Index1 on #T1(C2,C1)

Select * from #T1
where C1 in (69809,85132,31781,52323,87467,24347,99568,11243,54472,325,8546,10692,29053,97752,47466,19061,78849,21358,60939,79110,55862,26110,94280,
88809,68352,51910,91711,83793,73189,75001,39816)
and C2 in (39436,30287,7459,25990,40847)



|ROOT:EMIT Operator (VA = 5)
|
| |NESTED LOOP JOIN Operator (VA = 4) (Join Type: Inner Join)
| |
| | |NESTED LOOP JOIN Operator (VA = 2) (Join Type: Inner Join)
| | |
| | | |SCAN Operator (VA = 0)
| | | | FROM OR List
| | | | OR List has up to 5 rows of OR/IN values.
| | |
| | | |SCAN Operator (VA = 1)
| | | | FROM OR List
| | | | OR List has up to 31 rows of OR/IN values.
| |
| | |SCAN Operator (VA = 3)
| | | FROM TABLE
| | | #T1
| | | Index : Index1
| | | Forward Scan.
| | | Positioning by key.
| | | Keys are:
| | | C2 ASC
| | | C1 ASC
| | | Using I/O Size 64 Kbytes for index leaf pages.
| | | With LRU Buffer Replacement Strategy for index leaf pages.
| | | Using I/O Size 8 Kbytes for data pages.
| | | With LRU Buffer Replacement Strategy for data pages.

Table: #T1 scan count 155, logical reads: (regular= 465 apf=0 total= 465 ), physical reads: (regular=0 apf=0 total=0), apf IOs used=0

Так что как-то так.
...
Рейтинг: 0 / 0
10.02.2014, 23:47
| Ответить | Цитировать | Написать  
25 сообщений из 25, страница 1 из 1
Форумы / Sybase ASA, ASE, IQ [игнор отключен] [закрыт для гостей] / ASE15.7 непонятная оценка оптимизатора по составному индексу
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=55&msg=38555917&tid=2009876]:
 0ms
get settings:
 9ms
get forum list:
 15ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 135ms
get topic data:
 10ms
get forum data:
 3ms
get page messages:
 64ms
get tp. blocked users:
 1ms
others: 16ms
total:  259ms
созд. / загр.: 259ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]