SQL перекрывающиеся и многостолбцовые индексы

Question

Я пытаюсь настроить некоторые хранимые процедуры и задать вопрос по индексам. Я использовал советник по настройке, и они рекомендовали два индекса, оба для одной и той же таблицы. Проблема заключается в том, что один индекс предназначен для одного столбца, а другой - для нескольких столбцов, из которых он включает один и тот же столбец из первого. У меня вопрос, почему и в чем разница?

CREATE NONCLUSTERED INDEX [_dta_index_Table1_5_2079723603__K23_K17_K13_K12_K2_K10_K22_K14_K19_K20_K9_K11_5_6_7_15_18]
ON [dbo].[Table1]  (    
    [EfctvEndDate] ASC,     
    [StuLangCodeKey] ASC,
    [StuBirCntryCodeKey] ASC,
    [StuBirStOrProvncCodeKey] ASC,
    [StuKey] ASC, 
    [GndrCodeKey] ASC,
    [EfctvStartDate] ASC,
    [StuHspncEnctyIndctr] ASC,
    [StuEnctyMsngIndctr] ASC,
    [StuRaceMsngIndctr] ASC,
    [StuBirDate] ASC,   
    [StuBirCityName] ASC 
) INCLUDE (
    [StuFstNameLgl],
    [StuLastOrSrnmLgl], 
    [StuMdlNameLgl],
    [StuIneligSnorImgrntIndctr],
    [StuExpctdGrdtngClYear]
) WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF) 
ON [PRIMARY] go

CREATE NONCLUSTERED INDEX [_dta_index_Table1_5_2079723603__K23]
ON [dbo].[Table1]  (
    [EfctvEndDate] ASC 
)WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF)     
ON [PRIMARY]

Answer 1

Если, как в вашем случае выше, один столбец является первым столбцом, определенным в многостолбцовом индексе: он не всегда делает это правильно, ИЛИ рабочая нагрузка запроса со временем изменилась. Если многостолбцовый индекс полезен и используется, вы можете удалить одностолбцовый индекс. НО, профилируйте и проверьте отчет об использовании индекса.

Если нет, то это применимо к различным запросам. Я заметил, что DTA любит создавать индекс, который по сути является копией всей таблицы, особенно в ситуациях, когда рабочая нагрузка запроса передается с помощью ORM.

Как и в этом и во всех других случаях, важно, чтобы вы профилировали, чтобы определить эффективность любых индексов по отношению к вашей «нормальной» рабочей нагрузке запроса.

Answer 2

«Автономный» индекс EfctvEndDate, в то время как функционально доступен в другом индексе, будет намного меньше и, следовательно, более эффективным (с точки зрения количества требуемых операций чтения, его способности кэшироваться , остаются в кеше и тд и тп.).

Это, конечно, во многом зависит от моделей использования и т. Д., Но да, в целом, весьма вероятно, что наличие нескольких явно избыточных индексов является чувствительным подходом.

Недостатки индекса "дублирование" в основном (и, вероятно, в порядке увеличения или уменьшения):

• Запросы INSERT / UPDATE / DELETE для базовой таблицы приводят к снижению производительности для поддержки дополнительных индексов.
• конкурс на использование кеша
• [очень немного] больше времени на создание планов запросов.
• издержки хранения (обычно не проблема; однако время резервного копирования увеличивается ...).

Поэтому необходимо оценить, компенсирует ли повышенная производительность запросов SELECT, которые могут извлечь выгоду из дополнительного индекса (-ов) недостаток, перечисленный выше. Настройка производительности базы данных - это, как правило, индивидуальное упражнение ...