Como Remus diz, depende da sua carga de trabalho.
Quero abordar um aspecto enganador da resposta aceita.
Para consultas que estão executando uma pesquisa de igualdade em todas as colunas no índice, não há diferença significativa.
O abaixo cria duas tabelas e as preenche com dados idênticos. A única diferença é que um tem as chaves ordenadas do mais para o menos seletivo e o outro, o inverso.
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;
Agora, fazendo uma consulta nas duas tabelas ...
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 = '~';
... Ambos usam uma multa de índice e recebem exatamente o mesmo custo.
A arte ASCII na resposta aceita não é de fato como os índices são estruturados. As páginas de índice da Tabela1 estão representadas abaixo (clique na imagem para abrir em tamanho real).
As páginas de índice contêm linhas que contêm a chave inteira (nesse caso, na verdade, há uma coluna de chave adicional anexada ao identificador de linha, pois o índice não foi declarado como único, mas que pode ser desconsiderado, informações adicionais sobre isso podem ser encontradas aqui ).
Para a consulta acima, o SQL Server não se importa com a seletividade das colunas. Ele faz uma pesquisa binária da página raiz e descobre que a chave (PPP...,3,~ ) é >=(JJJ...,1,~ )e < (SSS...,3,~ )deve ler a página 1:118. Em seguida, ele faz uma pesquisa binária das entradas principais nessa página e localiza a página da folha para a qual viajar.
Alterar o índice em ordem de seletividade não afeta o número esperado de comparações de chaves da pesquisa binária ou o número de páginas que precisam ser navegadas para fazer uma pesquisa no índice. Na melhor das hipóteses, pode acelerar marginalmente a própria comparação de chaves.
Às vezes, solicitar o índice mais seletivo primeiro fará sentido para outras consultas em sua carga de trabalho.
Por exemplo, se a carga de trabalho contiver consultas dos dois formulários a seguir.
SELECT * ... WHERE MostSelective = 'P'
SELECT * ...WHERE Least = '~'
Os índices acima não estão cobrindo para nenhum deles. MostSelectiveé seletivo o suficiente para fazer um plano com uma busca e pesquisas que valham a pena, mas a consulta contraLeast não é.
No entanto, esse cenário (busca de índice não abrangente no subconjunto de colunas principais de um índice composto) é apenas uma classe de consulta possível que pode ser ajudada por um índice. Se você nunca pesquisar MostSelectivesozinho ou uma combinação deMostSelective, SecondMost e sempre procurar por uma combinação das três colunas, essa vantagem teórica será inútil para você.
Por outro lado, consultas como
SELECT MostSelective,
SecondMost,
Least
FROM Table2
WHERE Least = '~'
ORDER BY SecondMost,
MostSelective
Seria ajudado por ter a ordem inversa da normalmente prescrita - já que abrange a consulta, pode suportar uma busca e retorna linhas na ordem desejada para inicializar.
Portanto, este é um conselho frequentemente repetido, mas, no máximo, é uma heurística sobre o benefício potencial para outras consultas - e não é um substituto para realmente analisar sua carga de trabalho.