¿Está bien agregar ciegamente índices faltantes?

A menudo uso SSMS para probar mis procedimientos almacenados lentos en busca de índices faltantes. Cada vez que veo un "Índice que falta (Impacto xxx)", mi reacción es simplemente crear el nuevo índice. Esto resulta en una consulta más rápida cada vez que puedo decir.

¿Alguna razón por la que no debería seguir haciendo esto?

Muchas razones.

Uno de los más grandes que se me ocurre es que los DMV de índice que faltan no tienen en cuenta los índices existentes.

Ejemplo:

Tienes una mesa con ColA, ColB, ColC.

Actualmente tienes un índice en ColA. El índice DMV que falta le sugerirá agregar un índice (ColA, ColB). Esto puede ser correcto, pero lo más inteligente es agregar ColBcomo segunda clave en el índice existente. De lo contrario, tiene cobertura duplicada y desperdicio de espacio y gastos generales.

Del mismo modo, si tiene un índice activado ColB INCLUDE (ColA), puede sugerir un índice activado ColB INCLUDE (ColC). Una vez más, lo más inteligente es agregar ColCa la lista de inclusión en el índice existente.

Los índices sugeridos tienen una vista extremadamente estrecha: solo miran una sola consulta o una sola operación dentro de una sola consulta. No tienen en cuenta lo que ya existe ni sus otros patrones de consulta.

Todavía necesita un ser humano pensante para analizar la estrategia de indexación general y asegurarse de que la estructura de indexación sea eficiente y coherente.

Si no hubiera problemas con solo agregar todos los índices sugeridos, entonces no habría necesidad de que se sugirieran, se implementarían automáticamente.

Recomiendo el uso cauteloso de esta técnica de ajuste, ya que he encontrado que las sugerencias de índice que faltan aparecidas por los planes de consulta son consistentemente menos confiables a medida que las consultas y los esquemas de DB se vuelven progresivamente más complejos. Esto se debe a una variedad de razones en mi experiencia:

1) La "mejora porcentual" puede ser muy diferente para todas las consultas más simples / índices más obvios, después de todo, es solo una estimación y no se deriva de los costos reales incurridos o los recuentos de filas reales cuando se ejecuta la consulta. He visto que los costos de consulta aumentan después de implementar un índice sugerido, o incluso no se usa y el plan sigue siendo el mismo.

2) El plan de consulta en sí no es óptimo, ya sea debido a la construcción de la consulta (uniones y cláusula where no optimizada, etc.), o las estimaciones de recuento de filas están desactivadas debido a estadísticas faltantes / desactualizadas. La indexación a un plan de consulta brutalmente malo suele ser, en el mejor de los casos, una solución de curita con solo una mejora incremental en el rendimiento.

3) Es posible que no esté viendo la imagen completa. Esto es especialmente cierto cuando se usa solo el plan gráfico y no se visualiza el XML para ver si se ha sugerido más de un índice faltante. El que se muestra primero en el plan gráfico no es necesariamente el que tiene mayor impacto en la consulta.

4) También he encontrado muchos ejemplos de nuevos índices que se sugieren al modificar el índice existente. Vea las otras respuestas aquí con respecto a este punto, son acertadas, no es necesario que profundice más.

Solo uso las sugerencias de índice que faltan como punto de partida cuando trabajo con una consulta / entorno desconocido para ver dónde buscar más a fondo. Obtuve mejores resultados mirando a los operadores en el plan (principalmente las búsquedas / escaneos / uniones) y comprobando la información sobre herramientas o la ventana de propiedades para ver qué columnas están involucradas y usar eso para determinar los candidatos de índice para evaluar la mejora.

Hay un montón de razones, principalmente, saber cómo funcionan y almacenan los índices, siempre creará un índice mejor, o al menos, no peor, que las sugerencias de SSMS