¿Un índice o dos?

Tengo el siguiente índice creado en una tabla en mi base de datos:

CREATE INDEX [idx_index1]
on [table1]
(col1, col2, col3)

El servidor sugiere el siguiente índice 'faltante':

CREATE INDEX [idx_index2]
on [table1]
(col1, col2)
INCLUDE (col3, col4, col5, col6....)

Me parece lógico enmendar la definición de índice existente para incluir las columnas sugeridas, en lugar de crear un nuevo índice que deba mantenerse. Una consulta que selecciona col1 y col2 podría usar index1 con la misma eficacia que index2. ¿Estoy en lo cierto o tal vez me estoy perdiendo algo?

Y así entra en el arte del ajuste del rendimiento y las estrategias de indexación ...

Me parece lógico enmendar la definición de índice existente para incluir las columnas sugeridas

Voy a tomar su presupuesto y escribir una tercera definición de índice:

create index [idx_index3]
on [table1] (col1, col2, col3)
include (col4, col5, col6....);

Esa debería ser la CREATE INDEXdeclaración que corresponde a su declaración citada.

Eso muy bien puede ser una solución prudente, pero depende . Aquí hay un par de ejemplos cuando digo que depende.

Si tiene una carga de trabajo común que consiste principalmente en consultas como esta:

select col1, col2, col3
from table1
where col1 = 1
and col2 = 2
and col3 = 3;

Entonces su idx_index1índice sería sólido. Perfectamente estrecho, es un índice que satisface esa consulta sin datos extraños (sin tener en cuenta la definición del índice agrupado, si es que lo hay).

Pero si tiene una carga de trabajo que consiste en consultas principalmente como las siguientes:

select co11, col2, col3, col4, col5
from table1
where col1 = 1
and col2 = 2;

Entonces idx_index2sería prudente, ya que es lo que se llama un índice de cobertura que evita la necesidad de una búsqueda de clave de regreso al índice agrupado (o una búsqueda de RID de regreso al montón). Esa definición de índice no agrupado abarcaría únicamente todos los datos que necesita la consulta.

Con su recomendación, sería adecuado para una consulta como la siguiente:

select co11, col2, col3, col4, col5
from table1
where col1 = 1
and col2 = 2
and col3 = 3;

Su idx_index3recomendación sería un índice de cobertura que satisfaga los criterios de búsqueda para la consulta anterior.

El punto al que estoy tratando de llegar es una pregunta aislada como esta, no podemos responder esto definitivamente. Todo depende de cuál sea la carga de trabajo común y frecuente. Por supuesto, siempre puede definir estos tres índices para manejar cada tipo de consulta de muestra, pero luego se pone en duda el mantenimiento que se necesitará para mantener estos índices actualizados (piense: INSERT, ACTUALIZACIONES, DELETES). Esa es la sobrecarga de los índices.

Necesita diseccionar y evaluar la carga de trabajo, y determinar dónde serán las mejores ventajas. Si la primera consulta de muestra es la más común que se ejecuta decenas de veces por segundo, y hay una consulta muy poco frecuente como la tercera consulta de muestra, entonces no tendría sentido hinchar las páginas a nivel de hoja del índice con el INCLUDEcolumnas sin clave. Todo depende de tu carga de trabajo.

Si comprende estrategias de indexación prudentes y comprende su carga de trabajo común, al aplicar ambas podrá encontrar cuál es la mejor ruta a seguir.

De hecho, tiene razón y ha descubierto por qué es importante que un DBA siempre revise las "sugerencias" presentadas por los DMV de índice que faltan, etc.

Tenga en cuenta que las sugerencias ofrecidas por los DMV de índice que faltan se presentan de forma aislada, lo que significa que SQL Server decidió que un índice de la estructura recomendada beneficiaría la consulta, independientemente de qué otras estructuras de índice puedan existir.

Un poco más, sobre una de las implicaciones de la respuesta de Thomas:

Él dijo:

Por supuesto, siempre puede definir estos tres índices para manejar cada tipo de consulta de muestra, pero luego se pone en duda el mantenimiento que se necesitará para mantener estos índices actualizados (piense: INSERT, ACTUALIZACIONES, DELETES). Esa es la sobrecarga de los índices.

Entonces, otra gran pregunta es: ¿con qué frecuencia se actualiza la tabla?

Considere primero un ejemplo de una tabla que se actualiza constantemente , como por ejemplo, una ORDERStabla minorista que refleja la actividad del consumidor del sitio web ... allí, debe ser consciente de tener múltiples índices, ya que aumentan el trabajo realizado por actualizaciones constantes, y por lo tanto afectar constantemente el rendimiento de la base de datos.

Por otro lado, considere una tabla que solo se actualiza como parte de la configuración del sitio web (la tabla se actualiza UNA VEZ para la mayoría de los valores y los valores que se agregan con poca frecuencia), allí, las desaceleraciones de actualización no son una consideración. Múltiples índices podrían ralentizar las reconstrucciones y reorganizaciones del índice de la base de datos, pero siempre que sean lo suficientemente rápidos, SIENTE LIBRE: si múltiples índices aceleran las lecturas, hágalo.

Un caso intermedio podría ser una tabla que normalmente solo se actualiza en un proceso por lotes durante la noche. Allí, las ralentizaciones de actualización de múltiples índices no afectarían el rendimiento diurno : solo afectarían (1) el tiempo necesario, ejecutar ese mantenimiento nocturno por lotes, (2) el rendimiento de cualquier proceso concurrente y (3) el tiempo necesario para tareas de mantenimiento de bases de datos como reorganización de índices. Entonces, siempre y cuando los procesos en esas 3 arenas se ejecuten lo suficientemente rápido para usted ... cree los índices que aceleren las consultas.

HTH ...