Como dice Remus, depende de tu carga de trabajo.
Sin embargo, quiero abordar un aspecto engañoso de la respuesta aceptada.
Para las consultas que realizan una búsqueda de igualdad en todas las columnas del índice, no existe una diferencia significativa.
Lo siguiente crea dos tablas y las completa con datos idénticos. La única diferencia es que una tiene las claves ordenadas de la más selectiva a la menos selectiva y la otra al revés.
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;
Ahora haciendo una consulta en ambas tablas ...
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 usan una multa de índice y ambos reciben exactamente el mismo costo.
El arte ASCII en la respuesta aceptada no es, de hecho, cómo se estructuran los índices. Las páginas de índice para la Tabla 1 se representan a continuación (haga clic en la imagen para abrirla a tamaño completo).
Las páginas de índice contienen filas que contienen la clave completa (en este caso, en realidad hay una columna de clave adicional agregada para el identificador de fila, ya que el índice no se declaró como único, pero se puede descartar más información al respecto aquí ).
Para la consulta anterior, a SQL Server no le importa la selectividad de las columnas. Realiza una búsqueda binaria de la página raíz y descubre que la clave (PPP...,3,~ ) es >=(JJJ...,1,~ )y, < (SSS...,3,~ )por lo tanto, debe leer la página 1:118. Luego realiza una búsqueda binaria de las entradas clave en esa página y localiza la página de hoja para viajar hacia abajo.
La alteración del índice en orden de selectividad no afecta ni el número esperado de comparaciones clave de la búsqueda binaria ni el número de páginas que se deben navegar para realizar una búsqueda de índice. En el mejor de los casos, podría acelerar marginalmente la comparación de claves en sí.
Sin embargo, a veces ordenar primero el índice más selectivo tendrá sentido para otras consultas en su carga de trabajo.
Por ejemplo, si la carga de trabajo contiene consultas de las dos formas siguientes.
SELECT * ... WHERE MostSelective = 'P'
SELECT * ...WHERE Least = '~'
Los índices anteriores no cubren ninguno de ellos. MostSelectivees lo suficientemente selectivo como para hacer que un plan con una búsqueda y búsquedas valga la pena, pero la consulta en contra Leastno lo es.
Sin embargo, este escenario (búsqueda de índice no cubriente en el subconjunto de columnas principales de un índice compuesto) es solo una posible clase de consulta que puede ser ayudada por un índice. Si nunca buscas realmente porMostSelective sí solo o una combinación de MostSelective, SecondMosty siempre busca por una combinación de las tres columnas, esta ventaja teórica es inútil para usted.
Por el contrario, consultas como
SELECT MostSelective,
SecondMost,
Least
FROM Table2
WHERE Least = '~'
ORDER BY SecondMost,
MostSelective
Sería útil contar con el orden inverso al comúnmente recetado, ya que cubre la consulta, puede admitir una búsqueda y devuelve filas en el orden deseado para arrancar.
Por lo tanto, este es un consejo que se repite a menudo, pero a lo sumo es una heurística sobre el beneficio potencial de otras consultas, y no es un sustituto para analizar realmente su carga de trabajo.