отказ оптимизатора от специальной стратегии OR / Sybase ASA, ASE, IQ

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Sybase ASA, ASE, IQ [игнор отключен] [закрыт для гостей] / отказ оптимизатора от специальной стратегии OR

2 сообщений из 2, страница 1 из 1

отказ оптимизатора от специальной стратегии OR

#37523000

SQLMantis

Участник

Откуда: Москва

Сообщения: 238

Рейтинг: 0 / 0

Привет всем. Прошу посмотреть и высказать своем мнение по поводу следующего поведения оптимизатора.

Сервер: Adaptive Server Enterprise/12.5.4/EBF 14065 ESD#3/P/Sun_svr4/OS 5.8/ase1254/2030/64-bit/FBO/Sat Oct 14 07:19:31 2006
Преистория: От одного замечательного приложения приходит запрос, который однажды начал "тормозить"
После исследования выяснилось странное поведение оптимизатора, которое можно воспроизвести с помощью примера расписанного ниже.

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.

CREATE TABLE test1
(
    id numeric( 32 , 0 ) identity primary key,
    a_id numeric( 32 ) not null
)
LOCK ALLPAGES
go

create index test1_1 on test1(a_id)
go

declare @i numeric( 32 )
select @i =  5000 
while (@i <=  20000 )
begin
 insert into test1 (a_id) values (@i)
 select @i = @i +  1 
end

update statistics test1
go

Далее выполним следующий запрос:

Код: plaintext

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.

select id from test1 where a_id in (	
 5000 ,                               	
 5001 ,                               	
 5002 ,                               	
 5003 ,                               	
 5004 ,                               	
 5005 ,                               	
 5006 ,                               	
 5007 ,                               	
 5008 ,                               	
 5009 ,                               	
 5010 ,                               	
 5011 ,                               	
 5012 ,                               	
 5013 ,                               	
 5014 ,                               	
 5015 ,                               	
 5016 ,                               	
 5017 ,                               	
 5018 ,                               	
 5019 ,                               	
 5020 ,                               	
 5021 ,                               	
 5022 ,                               	
 5023 ,                               	
 5024 ,	
 5025 ,	
 5026 ,	
 5027 ,
 5028 ,
 5029 ,
 5030 
)

План запроса и статистика:

Код: plaintext

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.

QUERY PLAN FOR STATEMENT  1  (at line  1 ).


    STEP  1 
        The type of query is SELECT.

        FROM TABLE
            test1
        Nested iteration.
        Using  31  Matching Index Scans
        Index : test1_1
        Forward scan.
        Positioning by key.
        Keys are:
            a_id  ASC
        Index : test1_1
        Forward scan.
        Positioning by key.
        Keys are:
            a_id  ASC
        .......
        тут идет повторение секции Index : test1_1 для каждого элемента IN
        .......


 1 	Table: test1 scan count  31 , logical reads: (regular= 124  apf= 0  total= 124 ), physical reads: (regular= 4  apf= 0  total= 4 ), apf IOs used= 0 	   
 2 	Total writes for this command:  0 	   
 3 	 	   
 4 	Execution Time  0 .	   
 5 	SQL Server cpu time:  0  ms.  SQL Server elapsed time:  0  ms.

Теперь добавляем в IN еще одно значение:

Код: plaintext

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.

select id from test1 where a_id in (	
 5000 ,                               	
 5001 ,                               	
 5002 ,                               	
 5003 ,                               	
 5004 ,                               	
 5005 ,                               	
 5006 ,                               	
 5007 ,                               	
 5008 ,                               	
 5009 ,                               	
 5010 ,                               	
 5011 ,                               	
 5012 ,                               	
 5013 ,                               	
 5014 ,                               	
 5015 ,                               	
 5016 ,                               	
 5017 ,                               	
 5018 ,                               	
 5019 ,                               	
 5020 ,                               	
 5021 ,                               	
 5022 ,                               	
 5023 ,                               	
 5024 ,	
 5025 ,	
 5026 ,	
 5027 ,
 5028 ,
 5029 ,
 5030 ,
 5031 	
)

План запроса и статистика:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.

QUERY PLAN FOR STATEMENT  1  (at line  1 ).


    STEP  1 
        The type of query is SELECT.

        FROM TABLE
            test1
        Nested iteration.
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size  4  Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.

 1 	Table: test1 scan count  1 , logical reads: (regular= 127  apf= 0  total= 127 ), physical reads: (regular= 0  apf= 0  total= 0 ), apf IOs used= 0 	   
 2 	Total writes for this command:  0 	   
 3 	 	   
 4 	Execution Time  1 .	   
 5 	SQL Server cpu time:  100  ms.  SQL Server elapsed time:  60  ms.

Есть идеи почему оптимизатор отказывается от специальной стратегии OR?

...

Рейтинг:

0 / 0

11.11.2011, 20:14

| Ответить | Цитировать | Написать

отказ оптимизатора от специальной стратегии OR

#37525640

cherrex_Den

Гость

SQLMantis,

Вполне ожидаемое поведение!

Судя по плану, полный table scan стоит 127 чтений, а выбранная стратегия OR при 31-ом значении в IN, стоит больше. Это легко проверить, указав в запросе с 31-значением хинт индекса

Код: plaintext

select id from test1 (index test1_1) where a_id in(....

...

Рейтинг:

0 / 0

14.11.2011, 15:03

| Ответить | Цитировать | Написать

2 сообщений из 2, страница 1 из 1

Форумы / Sybase ASA, ASE, IQ [игнор отключен] [закрыт для гостей] / отказ оптимизатора от специальной стратегии OR

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=55&msg=37523000&tid=2010215]:	0ms
get settings:	9ms
get forum list:	12ms
check forum access:	3ms
check topic access:	3ms
track hit:	167ms
get topic data:	9ms
get forum data:	2ms
get page messages:	41ms
get tp. blocked users:	1ms
others:	17ms

total:	264ms