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

Откуда: Москва
Сообщений: 180
Есть таблица T с более чем 50 млн. записей вида:

ID int; idGroup int; d datetime2; с1;с2;…сN

На поле ID установлен кластерный Pimary key
На поле idGroup установлен Forfeign Key + некластерный индекс по нему:

CREATE NONCLUSTERED INDEX [IX] ON T (idGroup DESC)

По таблице T идут довольно активно SELECT, INSERT, DELETE + UPDATE тоже индексированных полей с1, с2,…сN
В Ходе изучения проблемных запросов было принято решение создать индекс:

CREATE NONCLUSTERED INDEX [_IX] ON T (idGroup DESC, d DESC) INCLUDE (Id)

Очевидно, что при создании [_IX] упадет производительность запросов INSERT и DELETE

Вопрос:
Повлияет ли на выполнение каких либо запросов SELECT + UPDATE индексированных полей с1, с2,…сN
удаление индекса [IX] если вместо него появится [_IX] в котором первым полем стоит то же самое поле idGroup?

И если повлияет, то на какого рода запросы ? Где можно ждать падение производительности?
3 ноя 16, 09:31    [19853533]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизирование индекса  [new]
iljy
Member

Откуда:
Сообщений: 8711
Молодой,

1. INCLUDE(ID) - это масло масляное, ключ кластерного индекса и так добавляется в любой некластерный.
2. при наличии индекса (idGroup, d) индекс (idGroup) лишний. Хотя теоретически индекс по двум полям занимает больше места и будет работать чуть медленнее из-за увеличившегося количества чтений, на практике этой разницы вы никогда не заметите.
3. На UPDATE "индексированных полей c1..cN" наличие индекса (idGroup, d) не повлияет вообще никак, потому что эти поля в индекс не входят.
4. Необходимость индексов по "индексированным полям c1..cN" довольна сомнительна, тут все очень сильно зависит от их селективности и используемых запросов. Помониторьте статистику их использования, очень может быть, что они не используются никогда, потому что оптимизатор предпочитает сканирование кластерного.
3 ноя 16, 09:52    [19853646]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизирование индекса  [new]
Молодой
Member

Откуда: Москва
Сообщений: 180
iljy,
Про "INCLUDE(ID) - это масло масляное, ключ кластерного индекса и так добавляется в любой некластерный"
- я тоже так думал, просто принял на веру (не проверив) рекомендации от MISSING INDEX

По поводу практической ненужности индекса (idGroup) при наличии индекса (idGroup, d) - несколько сомневался...

Спасибо за советы! Появилась уверенность в правильности решения )
3 ноя 16, 10:02    [19853702]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизирование индекса  [new]
Молодой
Member

Откуда: Москва
Сообщений: 180
iljy
... индекс по двум полям занимает больше места и будет работать чуть медленнее из-за увеличившегося количества чтений, на практике этой разницы вы никогда не заметите.


На самом деле разницу заметил!

При [IX] в таблице, запросы типа
Select TOP 50 ID,  idGroup, d from T (with nolock) where idGroup IN (....) order by d desc 

выполняются за 500 ms, а при [_IX] за 1700 ms

Самое западло что при наличии обоих индексов скорость будет 1700 пока не грохнешь [_IX]
- почему то план упорно его берет по умолчанию.

Проблема теперь в том, что индекс [_IX] - нужен, а указанный Select TOP 50
должен быть быстрее 1 секунды...
3 ноя 16, 13:28    [19855267]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизирование индекса  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
Молодой
iljy
... индекс по двум полям занимает больше места и будет работать чуть медленнее из-за увеличившегося количества чтений, на практике этой разницы вы никогда не заметите.


На самом деле разницу заметил!

план покажите
3 ноя 16, 13:36    [19855337]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизирование индекса  [new]
iljy
Member

Откуда:
Сообщений: 8711
Молодой,

покажите план, не верю. В IX нет поля d, так что ему пришлось бы еще в кластерный лазить (скорее всего он это и делает). и nolock уберите.
3 ноя 16, 13:37    [19855345]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизирование индекса  [new]
Молодой
Member

Откуда: Москва
Сообщений: 180
Планы во вложении

К сообщению приложен файл (SQL_Plans.zip - 22Kb) cкачать
3 ноя 16, 14:05    [19855522]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизирование индекса  [new]
Молодой
Member

Откуда: Москва
Сообщений: 180
Тормоз я... забыл про [индекс по d]...

если заменяем IX на _IX надо просто добавить в запрос
... with (nolock, index ([индекс по d]))

В общем ... with (nolock, index (IX_Object_AppTime)) - всё поставило на свои места.

Извините за беспокойство )
3 ноя 16, 14:35    [19855724]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизирование индекса  [new]
iljy
Member

Откуда:
Сообщений: 8711
Молодой,

я не понял, какие индексы и какие поля в запросе соответствуют полям в обсуждаемом индексе, но планы совершенно разные, так что проблема точно не связана с чтениями из индекса. И не надо злоупотреблять хинтами, если оптимизатор что-то выбирает, то скорее всего не просто так.
3 ноя 16, 14:46    [19855791]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизирование индекса  [new]
Молодой
Member

Откуда: Москва
Сообщений: 180
iljy
Молодой,

я не понял, какие индексы и какие поля в запросе соответствуют полям в обсуждаемом индексе, но планы совершенно разные, так что проблема точно не связана с чтениями из индекса. И не надо злоупотреблять хинтами, если оптимизатор что-то выбирает, то скорее всего не просто так.


Всё правильно - проблема не связана с чтениями из индекса,
но тут именно тот случай, когда именно хинтом всё и решилось.
Вопрос снят.

Еще раз спасибо за ответы!
3 ноя 16, 15:29    [19856082]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизирование индекса  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
Молодой
iljy
Молодой,

я не понял, какие индексы и какие поля в запросе соответствуют полям в обсуждаемом индексе, но планы совершенно разные, так что проблема точно не связана с чтениями из индекса. И не надо злоупотреблять хинтами, если оптимизатор что-то выбирает, то скорее всего не просто так.


Всё правильно - проблема не связана с чтениями из индекса,
но тут именно тот случай, когда именно хинтом всё и решилось.
Вопрос снят.

Еще раз спасибо за ответы!

хинт убрать, REOMPILE добавить и смотреть
3 ноя 16, 15:41    [19856160]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизирование индекса  [new]
o-o
Guest
попробуйте индекс (ObjectAppTime desc, ObjectId desc) include(CameraID)
---
d = ObjectAppTime????
3 ноя 16, 15:58    [19856258]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизирование индекса  [new]
o-o
Guest
TaPaK
хинт убрать, REOMPILE добавить и смотреть

а что смотреть, у него и так Compiled value = Runtime value.
а вот индекс неправильный.
3 ноя 16, 16:42    [19856507]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизирование индекса  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
o-o
TaPaK
хинт убрать, REOMPILE добавить и смотреть

а что смотреть, у него и так Compiled value = Runtime value.
а вот индекс неправильный.

да, но это пока он не начал передавать.

join #filteredSources fs on (o.CameraId = fs.SourceId) 

правильнее в exists переписать

автор
o.ObjectId <= IsNull(@begId,o.ObjectId)

я предпочитаю
(@begId IS NULL OR @begId >= o.ObjectId )

но есть и противники, без RECOMPILE с этим не жизнь
3 ноя 16, 17:55    [19856874]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизирование индекса  [new]
o-o
Guest
я не об абстрактном будущем рассуждаю,
а о его печальном настоящем.
в третий раз: индекс неправильный.
3 ноя 16, 18:17    [19856969]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить