Как говорит Ремус, это зависит от вашей рабочей нагрузки.
Я хочу обратиться к вводящему в заблуждение аспекту принятого ответа.
Для запросов, которые выполняют поиск равенства во всех столбцах вВ индексе нет существенной разницы.
Ниже приведены две таблицы и заполнены ими с идентичными данными.Единственное отличие состоит в том, что у одного есть ключи, упорядоченные от большинства к наименее селективным, а у другого - наоборот.
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
Помогло бы наличие обратного порядка обычно назначаемого - поскольку он охватывает запрос, может поддерживать поиск и возвращает строки в нужном порядке.
Так что это часто повторяемый совет, но, в большинстве случаев, это эвристика о потенциальной выгоде других запросов - и это не заменит фактически просмотр ваша рабочая нагрузка.