І так входить у мистецтво налаштування ефективності та стратегії індексування ...
Мені здається логічним змінити існуюче визначення індексу, щоб включити запропоновані стовпці
Я візьму вашу пропозицію і напишу визначення третього індексу:
create index [idx_index3]
on [table1] (col1, col2, col3)
include (col4, col5, col6....);
Це має бути CREATE INDEXтвердження, яке відповідає вашому цитованому твердженню.
Це дуже добре може бути розумним рішенням, але це залежить . Ось кілька прикладів, коли я кажу, що це залежить.
Якщо у вас є загальна навантаження, яка в основному складається з таких запитів:
select col1, col2, col3
from table1
where col1 = 1
and col2 = 2
and col3 = 3;
Тоді ваш idx_index1індекс буде суцільним. Ідеально вузький - це індекс, який задовольняє цей запит, не маючи в ньому сторонніх даних (без урахування кластерного визначення індексу, якщо такий взагалі є).
Але якщо у вас є навантаження, яка складається з запитів, як правило, таких:
select co11, col2, col3, col4, col5
from table1
where col1 = 1
and col2 = 2;
Тоді idx_index2було б розумно, оскільки це називається покривним індексом, що перешкоджає необхідності пошуку ключа назад до кластерного індексу (або пошуку RID назад до купи). Це некластеризоване визначення індексу охоплювало б виключно всі дані, які потребують запиту.
З вашою рекомендацією, він цілком підходить для запиту на зразок наступного:
select co11, col2, col3, col4, col5
from table1
where col1 = 1
and col2 = 2
and col3 = 3;
Вашою idx_index3рекомендацією буде індекс покриття, який задовольняє критеріям пошуку вищезазначеного запиту.
Справа, яку я намагаюся досягти, полягає в такому відокремленому питанні, на яке ми не можемо відповісти остаточно. Все залежить від того, яке загальне та часте навантаження. Звичайно, ви завжди можете визначити всі ці три індекси для обробки кожного типу вибіркового запиту, але тоді виникає сумнів у технічному обслуговуванні, яке потребуватиме постійного оновлення цих індексів (подумайте: ВСТАВКИ, ОНОВЛЕННЯ, ВИДАЛЕННЯ). Ось накладні показники.
Потрібно розчленувати та оцінити навантаження та визначити, де переваги будуть найкращими. Якщо перший вибірковий запит є найпоширенішим, на сьогоднішній день виконується десятки разів в секунду, і є дуже рідкісний запит, як третій зразок запиту, тоді не було б сенсу роздувати сторінки на рівні аркушів в індексі INCLUDEстовпчики без ключа. Все залежить від вашої завантаженості.
Якщо ви розумієте розсудливі стратегії індексації та розумієте вашу загальну завантаженість, застосувавши обидві, ви зможете придумати найкращий шлях.