Як каже Ремус, це залежить від вашої завантаженості.
Хоча я хотів би вирішити оманливий аспект прийнятої відповіді.
Для запитів, які здійснюють пошук рівності у всіх стовпцях індексу, суттєвої різниці немає.
Нижче створено дві таблиці та заповнено їх однаковими даними. Єдина відмінність полягає в тому, що один має клавіші, упорядковані від більшості до найменш вибіркових, а у іншого - зворотним.
CREATE TABLE Table1(MostSelective char(800), SecondMost TINYINT, Least CHAR(1), Filler CHAR(4000) null);
CREATE TABLE Table2(MostSelective char(800), SecondMost TINYINT, Least CHAR(1), Filler CHAR(4000) null);
CREATE NONCLUSTERED INDEX MyINDX on Table1(MostSelective,SecondMost,Least);
CREATE NONCLUSTERED INDEX MyINDX2 on Table2(Least,SecondMost,MostSelective);
INSERT INTO Table1 (MostSelective, SecondMost, Least)
output inserted.* into Table2
SELECT TOP 26 REPLICATE(CHAR(number + 65),800), number/5, '~'
FROM master..spt_values
WHERE type = 'P' AND number >= 0
ORDER BY number;
Тепер робимо запит проти обох таблиць ...
SELECT *
FROM Table1
WHERE MostSelective = REPLICATE('P', 800)
AND SecondMost = 3
AND Least = '~';
SELECT *
FROM Table2
WHERE MostSelective = REPLICATE('P', 800)
AND SecondMost = 3
AND Least = '~';
... Обидва вони використовують індексний штраф і обом отримують точно однакову вартість.
Мистецтво ASCII у прийнятій відповіді - це насправді не структура структури індексів. Сторінки індексу для таблиці1 представлені нижче (натисніть на зображення, щоб відкрити в повному розмірі).
Сторінки індексу містять рядки, що містять весь ключ (у цьому випадку насправді є додатковий стовпець ключа, доданий до ідентифікатора рядка, оскільки індекс не був оголошений унікальним, але його можна не враховувати. Додаткову інформацію про це можна знайти тут ).
Для запиту вище SQL Server не дбає про вибірковість стовпців. Він виконує двійковий пошук кореневої сторінки і виявляє, що ключ (PPP...,3,~ ) є, >=(JJJ...,1,~ )і < (SSS...,3,~ )тому він повинен читати сторінку 1:118. Потім він виконує двійковий пошук ключових записів на цій сторінці та розміщує сторінку аркуша, на яку слід переходити.
Зміна індексу в порядку вибірковості не впливає ні на очікувану кількість ключових порівнянь двійкового пошуку, ні на кількість сторінок, за якими потрібно здійснювати пошук індексу. У кращому випадку це може незначно прискорити саме порівняння ключів.
Іноді спочатку замовлення найбільш селективного індексу має сенс для інших запитів у вашому навантаженні.
Наприклад, якщо робоче навантаження містить запити обох наступних форм.
SELECT * ... WHERE MostSelective = 'P'
SELECT * ...WHERE Least = '~'
Показники вище не охоплюють жодного з них. MostSelectiveє достатньо вибірковим, щоб скласти план із пошуком і пошуком, але запит проти Least- ні.
Однак цей сценарій (не охоплюючи пошук індексу на підмножину провідних стовпців (ів) складеного індексу) є лише одним із можливих класів запитів, яким може допомогти індекс. Якщо ви ніколи не шукаєте MostSelectiveсамостійно або за комбінацією MostSelective, SecondMostі завжди шукаєте за допомогою комбінації всіх трьох стовпців, тоді ця теоретична перевага для вас марна.
І навпаки запити, такі як
SELECT MostSelective,
SecondMost,
Least
FROM Table2
WHERE Least = '~'
ORDER BY SecondMost,
MostSelective
Допоможе, якщо у зворотному порядку є загальнопризначений - оскільки він охоплює запит, може підтримувати пошук і повертає рядки в потрібному порядку для завантаження.
Отже, це часто повторювані поради, але щонайбільше це евристика про потенційну користь для інших запитів - і це не є заміною для того, щоб насправді дивитися на ваше навантаження.