Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 execution plan  [new]
Ярослав Демин
Member

Откуда:
Сообщений: 161
Добрый день!

Коллеги, помогите разобраться.
Имеем два запроса
1. Select * From Table1 Order By Id_Field.
2. Select * From Table1 With(Index(ix_id_Field)) Order By Id_Field.

Поле Id_Field индексировано по возрастанию.
При запросе 1 оптимизатор использует кластерный индекс и выполняется 38 секунд, при запросе 2 используется указанный индекс и выполняется 23 секунды.

Вопрос почему оптимизатор сам не определил более быстрое решение?

PS. Уважаемы pkarklin указывал ссылку, где было сказано, что если возвращается более определенного % данных, то используется кластерный индекс. Это было в статье почему одинаковые на вид запросы выполняются разное время
29 июн 04, 12:50    [771049]     Ответить | Цитировать Сообщить модератору
 Re: execution plan  [new]
Предводитель команчей
Member

Откуда: Днепропетровск
Сообщений: 321
1.Оптимизатор не всегда выбирает правильный план выполнения.
2.В вашем случае возвращается весь набор, поэтому оптимизатор тупо идет по кластерному индексу. Поставте where посмотрите что получится.
29 июн 04, 12:57    [771090]     Ответить | Цитировать Сообщить модератору
 Re: execution plan  [new]
Ray D
Member

Откуда: from the middle of nowhere
Сообщений: 3598
Блог
А селективность/плотность индекса какая?
29 июн 04, 12:58    [771095]     Ответить | Цитировать Сообщить модератору
 Re: execution plan  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
Структуру таблиц с индексами и планы выполнения запросов в студию. Скока записей в таблице? Какова селективность индекса?

ЗЫ. Странно, однако, тюнить выборку типа SELECT * FROM Table без WHERE.
29 июн 04, 13:03    [771118]     Ответить | Цитировать Сообщить модератору
 Re: execution plan  [new]
Ярослав Демин
Member

Откуда:
Сообщений: 161
Предводитель команчей
Поставте where посмотрите что получится.

С условием where без указания индекса все равно используется кластерный индекс

Ray D
А селективность/плотность индекса какая?

Если скажу что обычная по умолчаю, это как-нибудь поможет? я их не менял-настраивал никогда, так как еще не знаю
29 июн 04, 13:04    [771124]     Ответить | Цитировать Сообщить модератору
 Re: execution plan  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
автор
Если скажу что обычная по умолчаю, это как-нибудь поможет? я их не менял-настраивал никогда, так как еще не знаю


Селективность индекса определяется не какими то там настройками, а отношением уникальных значений этого поля к общему числу записей.
29 июн 04, 13:07    [771137]     Ответить | Цитировать Сообщить модератору
 Re: execution plan  [new]
Ray D
Member

Откуда: from the middle of nowhere
Сообщений: 3598
Блог
если у индекса низкая селективность/высокая плотность, он вообще не будет рассматриваться оптимизатором
29 июн 04, 13:10    [771146]     Ответить | Цитировать Сообщить модератору
 Re: execution plan  [new]
Ярослав Демин
Member

Откуда:
Сообщений: 161
pkarklin
ЗЫ. Странно, однако, тюнить выборку типа SELECT * FROM Table без WHERE.


Я не занимаюсь тюнингом этого запроса:) я хочу понять нужно ли мне в более сложных функциях явно указывать индексы для использования или довериться отпимизатору. И вот на простейшем запросе я встаю в тупик от результата.
29 июн 04, 13:11    [771153]     Ответить | Цитировать Сообщить модератору
 Re: execution plan  [new]
Предводитель команчей
Member

Откуда: Днепропетровск
Сообщений: 321
Кстати, раз уж зашел такой разговор, хочу полюбопытствовать, как народ выбирает наиболее подходящие индексы. Мой подход такой :
Есть табличка с индексами Field1+Field2+Field3 и Field1+Field3+Field2
Какой индекс выбрать ?
Делаю обновление статистик.
Делаю dbcc show_statistics на табличке и индексах, получаю плотность.
Выбираю индекс с наименьшей плотностью.
29 июн 04, 13:13    [771162]     Ответить | Цитировать Сообщить модератору
 Re: execution plan  [new]
Ray D
Member

Откуда: from the middle of nowhere
Сообщений: 3598
Блог
Приведите результат
DBCC SHOW_STATISTICS для индексов,
можно еще DBCC SHOWCONTIG
29 июн 04, 13:14    [771170]     Ответить | Цитировать Сообщить модератору
 Re: execution plan  [new]
Ярослав Демин
Member

Откуда:
Сообщений: 161
pkarklin
Селективность индекса определяется не какими то там настройками, а отношением уникальных значений этого поля к общему числу записей.

Уникальных значений - 50
Всего записей 148 тысяч
29 июн 04, 13:15    [771173]     Ответить | Цитировать Сообщить модератору
 Re: execution plan  [new]
Предводитель команчей
Member

Откуда: Днепропетровск
Сообщений: 321
автор
Уникальных значений - 50
Всего записей 148 тысяч


Скан таблицы однозначно.
29 июн 04, 13:17    [771182]     Ответить | Цитировать Сообщить модератору
 Re: execution plan  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
[quot Ярослав ДеминУникальных значений - 50
Всего записей 148 тысяч[/quot]
А приведите планы обоих запросов.
29 июн 04, 13:18    [771186]     Ответить | Цитировать Сообщить модератору
 Re: execution plan  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
Предводитель команчей
автор
Уникальных значений - 50
Всего записей 148 тысяч


Скан таблицы однозначно.

Дык он хоть как скан (тянутся то все строки)... Тока в одно случае... Короче, щаз увидим если он план покажет
29 июн 04, 13:19    [771190]     Ответить | Цитировать Сообщить модератору
 Re: execution plan  [new]
aag
Member

Откуда: Москва
Сообщений: 1955
У меня, может быть, неверный подход, но... простой. После перехода на 2000-й, я не указываю индексы в хинтах и полагаюсь на оптимизатор. Если время запроса меня удовлетворяет - т.е. оно меньше некой абсолютной величины (на глаз, зависит от запроса) - то ничего и править. А вот если больше - то начинаю выяснять, где узкое место. Но на практике, за 2 года, были считанные разы, когда оптимизатор выбирал неоптимальный план запроса. В осоновном, это были джойны кучи таблиц, пересеченные не по PK.

Nobody faults but mine... (LZ)
29 июн 04, 13:20    [771200]     Ответить | Цитировать Сообщить модератору
 Re: execution plan  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
автор
я хочу понять нужно ли мне в более сложных функциях явно указывать индексы для использования или довериться отпимизатору. И вот на простейшем запросе я встаю в тупик от результата.


Ну а я о чем говорю. Ну не тот вы запрос выбрали для проверки результата. Вы выбираете ВСЕ записи из таблицы, что приведет к сканированию кластерного индекса без хинта или к сканированию некластерного с хинтом, но без последующей сортировки. Не исключено, что второй запрос быстрее отработает, так как в первом варианте будет еще и сортировка присутсвовать. Хотя и не факт. В следующем варианте второй запрос медленнее.

SELECT * FROM sysobjects ORDER BY parent_obj

SELECT * FROM sysobjects  With(Index(ncsysobjects2)) ORDER BY parent_obj

А то, что оптимизатор не всегда самый быстрый план выбирает, уже говорилось не мало. Так что же с селективностью?
29 июн 04, 13:23    [771215]     Ответить | Цитировать Сообщить модератору
 Re: execution plan  [new]
Даутов
Member

Откуда: Казань
Сообщений: 502
При выборке всей таблицы оптимизатору неважны селективность и плотность индекса. В данном случае Вы выбираете все поля таблицы и оптимизатор посчитал, что дешевле отсортировать таблицу, не пользуясь индексом, чем от каждой записи в индексе переходить к записи данных. Принял он это решение, вероятно, основываясь на числе записей в таблице и длине записи.

Дополнительно :
Не сказалась ли на результате очередность запуска запросов (насколько стабильно указанное соотношение при многократных запусках) ?
29 июн 04, 13:24    [771219]     Ответить | Цитировать Сообщить модератору
 Re: execution plan  [new]
Ярослав Демин
Member

Откуда:
Сообщений: 161
[quot tpgДык он хоть как скан (тянутся то все строки)... Тока в одно случае... Короче, щаз увидим если он план покажет[/quot]

1. Оптимизатор выбирает индекс
|--Sort(ORDER BY:([Dispetcher].[Id_Orgs_Carrier] ASC))
|--Clustered Index Scan(OBJECT:([DustMove].[dbo].[Dispetcher].[IX_DateTime]))

2. Явно указанный индекс
|--Bookmark Lookup(BOOKMARK:([Bmk1000]), OBJECT:([DustMove].[dbo].[Dispetcher]))
|--Index Scan(OBJECT:([DustMove].[dbo].[Dispetcher].[IX_Dispetcher_Id_Orgs_Carrier]), ORDERED FORWARD)
29 июн 04, 13:26    [771226]     Ответить | Цитировать Сообщить модератору
 Re: execution plan  [new]
Ray D
Member

Откуда: from the middle of nowhere
Сообщений: 3598
Блог
И что говорит с
set statistics io on
?
29 июн 04, 13:28    [771246]     Ответить | Цитировать Сообщить модератору
 Re: execution plan  [new]
Ярослав Демин
Member

Откуда:
Сообщений: 161
pkarklin


Ну а я о чем говорю. Ну не тот вы запрос выбрали для проверки результата.


Ага, ясно...
я возму реальную ф-цию и поверчу с разных позиций:)
29 июн 04, 13:32    [771265]     Ответить | Цитировать Сообщить модератору
 Re: execution plan  [new]
Ярослав Демин
Member

Откуда:
Сообщений: 161
Даутов
Не сказалась ли на результате очередность запуска запросов (насколько стабильно указанное соотношение при многократных запусках) ?

Нет, очередность не сказалась.
Соотношение более-менее стабильно. С первоначальных 38 секунд ускорилось до 30 секунд, второй запрос с первоначальных 23 секунд ускорился до 20 секунд
29 июн 04, 13:33    [771280]     Ответить | Цитировать Сообщить модератору
 Re: execution plan  [new]
Даутов
Member

Откуда: Казань
Сообщений: 502
Предводитель команчей
Кстати, раз уж зашел такой разговор, хочу полюбопытствовать, как народ выбирает наиболее подходящие индексы. Мой подход такой :
Есть табличка с индексами Field1+Field2+Field3 и Field1+Field3+Field2
Какой индекс выбрать ?
Делаю обновление статистик.
Делаю dbcc show_statistics на табличке и индексах, получаю плотность.
Выбираю индекс с наименьшей плотностью.


Старшинство полей в составном индекск определяется уникальностью значения поля - самое первое поле должно быть наиболее уникальным.
Одновременное присутствие индексов Field1+Field2+Field3 и Field1+Field3+Field2 - бессмысленно
29 июн 04, 13:35    [771293]     Ответить | Цитировать Сообщить модератору
 Re: execution plan  [new]
Ярослав Демин
Member

Откуда:
Сообщений: 161
Ray D
И что говорит с
set statistics io on
?


1. Оптимизатор
Table 'Dispetcher'. Scan count 1, logical reads 2885, physical reads 0, read-ahead reads 0.

2. Индекс
Table 'Dispetcher'. Scan count 1, logical reads 414534, physical reads 0, read-ahead reads 0.
29 июн 04, 13:46    [771346]     Ответить | Цитировать Сообщить модератору
 Re: execution plan  [new]
Сергей Васкецов
Member

Откуда:
Сообщений: 20362
Предводитель команчей
автор
Уникальных значений - 50
Всего записей 148 тысяч

Скан таблицы однозначно.

Представьте себе список заголовков документов, их 148 тысяч, есть некое поле, определяющее тип документа, мне интересно получить все документы определенного типа. По этому полю имеется индекс.

Внимание (дзынь!), вопрос знатокам. Зачем table scan? Или IO уже ничего не стоят, чтобы их в 50 раз в среднем увеличить?

Более того, я вот только что проверил в рабочей системе (там с селективностью по типу документа еще хуже), никакого table scan не наблюдаю, идет именно по этому индексу (кстати, независимо от set rowcount перед запросом).
29 июн 04, 17:31    [772440]     Ответить | Цитировать Сообщить модератору
 Re: execution plan  [new]
Сергей Васкецов
Member

Откуда:
Сообщений: 20362
естественно, у меня индекс по полю типа не кластерный и в запросе по нему фильтрация
29 июн 04, 17:33    [772445]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить