SQL Overlapping и многоколоночные индексы

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, в то же время функционально доступны в другой индекс, будет намного меньше, и, следовательно, более эффективным (в отношении количества чтений требуется, чтобы его способность кэшировать , остаются в кеше и т. д.).

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

Недостатки индекса «дублирование» в основном (и, возможно, в порядке больше, меньшему воздействию):

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

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