Múltiples índices vs índices de múltiples columnas

646

Acabo de agregar un índice a una tabla en SQL Server 2005 y me hizo pensar. ¿Cuál es la diferencia entre crear 1 índice y definir múltiples columnas sobre tener 1 índice por columna que desea indexar?

¿Hay ciertas razones por las cuales una debe usarse sobre la otra?

Por ejemplo

Create NonClustered Index IX_IndexName On TableName
(Column1 Asc, Column2 Asc, Column3 Asc)

Versus

Create NonClustered Index IX_IndexName1 On TableName
(Column1 Asc)

Create NonClustered Index IX_IndexName2 On TableName
(Column2 Asc)

Create NonClustered Index IX_IndexName3 On TableName
(Column3 Asc)
GateKiller
fuente

Respuestas:

319

Estoy de acuerdo con Cade Roux .

Este artículo debería llevarte por el camino correcto:

Una cosa a tener en cuenta, los índices agrupados deben tener una clave única (una columna de identidad que recomendaría) como la primera columna. Básicamente, ayuda a que sus datos se inserten al final del índice y no causa muchas E / S de disco y divisiones de página.

En segundo lugar, si está creando otros índices en sus datos y se construyen de manera inteligente, se reutilizarán.

por ejemplo, imagina que buscas una tabla en tres columnas

estado, condado, código postal

  • a veces buscas solo por estado.
  • a veces busca por estado y condado.
  • busca con frecuencia por estado, condado, código postal.

Luego un índice con estado, condado, código postal. se usará en las tres búsquedas.

Si busca bastante solo con zip, entonces el índice anterior no se utilizará (de todos modos, SQL Server) ya que zip es la tercera parte de ese índice y el optimizador de consultas no verá ese índice como útil.

Luego, podría crear un índice solo en Zip que se usaría en esta instancia.

Por cierto , podemos aprovechar el hecho de que con la indexación de varias columnas, la primera columna de índice siempre se puede usar para buscar y cuando se busca solo por 'estado' es eficiente pero no tan eficiente como el índice de una sola columna en estado '

Supongo que la respuesta que está buscando es que depende de sus cláusulas where de sus consultas de uso frecuente y también de los by by de su grupo.

El artículo ayudará mucho. :-)

evilhomer
fuente
2
Entonces, ¿sería mejor definir un índice para estado, condado y código postal además de un índice individual para cada columna?
Maxim Zaslavsky
12
@jball ¿Me estoy perdiendo algo aquí? Parece que el artículo trata principalmente sobre las diferencias entre las limitaciones de la versión de SQL Server. ¿Se podría haber movido el artículo?
Ian R. O'Brien
@ Ian parece que algo se perdió en los próximos 3 años desde que resolví el enlace original desde hace más de 4 años. Puedo decirle que la publicación del blog tiene el título correcto al que fue vinculado por evilhomer, pero parece que los blogs de seguimiento de la serie ya no se pueden encontrar fácilmente desde esa primera publicación. Tendrás que revisar el archivo del blog de Kimberly para ver si puedes subir a los otros en la serie.
jball
1
1) "Básicamente [el índice agrupado con la columna IDENTIDAD como primera] ayuda a insertar los datos al final del índice" es correcto. "y no causar muchas E / S de disco y divisiones de página" es totalmente falso en un sistema multiusuario. La verdad es que garantiza una alta contención (baja concurrencia) en un sistema multiusuario. 2) El índice agrupado debe ser una clave relacional, es decir. no una IDENTITY, GUID, etc. 3) "Luego se utilizará un índice con estado, condado, código postal en las tres búsquedas". es falso y contradice "la primera columna es utilizable". Las columnas 2nd y subs en el índice no se pueden usar para la búsqueda.
PerformanceDBA
81

Si. Le recomiendo que consulte los artículos de Kimberly Tripp sobre indexación .

Si un índice está "cubriendo", entonces no hay necesidad de usar nada más que el índice. En SQL Server 2005, también puede agregar columnas adicionales al índice que no forman parte de la clave, lo que puede eliminar los viajes al resto de la fila.

Tener múltiples índices, cada uno en una sola columna puede significar que solo se utiliza un índice; deberá consultar el plan de ejecución para ver qué efectos ofrecen los diferentes esquemas de indexación.

También puede usar el asistente de ajuste para ayudar a determinar qué índices harían que una consulta o carga de trabajo funcione mejor.

Cade Roux
fuente
77
Kimberly Tripp sabe de qué está hablando. Estaba hablando de ella y ella sabe todo esto al revés. Buen consejo.
evilhomer
@CadeRoux Si la mayoría de las veces mi cláusula where tiene 2 columnas en la relación '&', ¿será mejor tener un índice de varias columnas en ellas o un índice de una sola columna en ambas
Es una trampa
2
@RachitGupta Un índice con ambas columnas
Cade Roux
40

El índice de varias columnas se puede usar para consultas que hacen referencia a todas las columnas:

SELECT *
FROM TableName
WHERE Column1=1 AND Column2=2 AND Column3=3

Esto se puede buscar directamente utilizando el índice de varias columnas. Por otro lado, como máximo se puede utilizar uno de los índices de una sola columna (tendría que buscar todos los registros que tengan Column1 = 1, y luego verificar Column2 y Column3 en cada uno de ellos).

MobyDX
fuente
24
Esto es correcto. Sin embargo, tener estas columnas como un índice único cada una aceleraría las cosas dramáticamente. Por lo general, uno de los valores en las columnas reducirá el conjunto resultante tanto que no importa buscar el resto sin un índice y el optimizador es bueno para elegir este valor.
TToni
16

Un elemento que parece haberse perdido son las transformaciones de estrellas. Los operadores de intersección de índice resuelven el predicado calculando el conjunto de filas alcanzado por cada uno de los predicados antes de realizar cualquier E / S en la tabla de hechos. En un esquema en estrella, indexaría cada clave de dimensión individual y el optimizador de consultas puede resolver qué filas seleccionar mediante el cálculo de intersección de índice. Los índices en columnas individuales dan la mejor flexibilidad para esto.

Preocupado por TunbridgeWells
fuente
+1 para la buena explicación vinculada de cómo se utilizan los índices (ordinarios), relevantes para la pregunta.
RobM
7

Si tiene consultas que utilizarán con frecuencia un conjunto de columnas relativamente estático, crear un único índice de cobertura que las incluya a todas mejorará drásticamente el rendimiento.

Al colocar varias columnas en su índice, el optimizador solo tendrá que acceder a la tabla directamente si una columna no está en el índice. Los uso mucho en el almacenamiento de datos. La desventaja es que hacer esto puede costar muchos gastos generales, especialmente si los datos son muy volátiles.

Crear índices en columnas individuales es útil para las operaciones de búsqueda que se encuentran con frecuencia en los sistemas OLTP.

Debería preguntarse por qué indexa las columnas y cómo se utilizarán. Ejecute algunos planes de consulta y vea cuándo se accede a ellos. El ajuste del índice es tan instinto como la ciencia.

Bob Probst
fuente