Descarte de índices no utilizados: evaluación de los peligros inesperados

Tenemos una base de datos muy grande con cientos de índices no utilizados según las estadísticas del DMV, que se han acumulado desde la última vez que se reinició el servidor en julio. Uno de nuestros DBA hizo las siguientes declaraciones de advertencia, que no tienen sentido para mí:

1. Antes de eliminar un índice, debemos asegurarnos de que no imponga una restricción de unicidad, ya que el optimizador de consultas puede necesitar que este índice exista.
2. Cada vez que se crea un índice, las estadísticas relacionadas con ese índice también se crean en SQL Server. Es posible que una consulta no esté usando el índice, pero podría estar usando sus estadísticas. Por lo tanto, podemos encontrarnos con una situación, después de soltar un índice, el rendimiento de una consulta en particular va realmente mal. SQL Server no mantiene las estadísticas de uso de las estadísticas. Aunque tenemos habilitada la función "Crear estadísticas automáticamente" en nuestra base de datos, no sé qué parámetros deben cumplirse internamente antes de que el optimizador de consultas cree las estadísticas que faltan.

Con respecto al n. ° 1, me parece que SQL Server realmente buscará en el índice para determinar la unicidad antes de que se realice una inserción / actualización y, por lo tanto, el índice no se mostrará como no utilizado.

Con respecto al n. ° 2, ¿es esto realmente posible?

Por cierto, cuando digo que no se usa un índice, quiero decir que no hay búsquedas ni escaneos.

Las preocupaciones de su DBA son válidas.

Con respecto al n. ° 1, me parece que SQL Server realmente buscará en el índice para determinar la unicidad antes de que se realice una inserción / actualización y, por lo tanto, el índice no se mostrará como no utilizado.

El optimizador puede usar la garantía de unicidad para decidir qué transformaciones lógicas u operaciones físicas se pueden usar para obtener resultados correctos. El hecho de que el optimizador se base en una garantía de unicidad para, por ejemplo, transformar una agregación o elegir una combinación de combinación uno a muchos, no se reflejará en las estadísticas de uso del índice, a menos que también se acceda físicamente al índice en el plan de ejecución final . Por lo tanto, se debe tener mucho cuidado al eliminar (o deshabilitar) cualquier índice o restricción únicos.

Con respecto al n. ° 2, ¿es esto realmente posible?

Sí, es posible que el optimizador use estadísticas asociadas con un índice sin el plan de ejecución final que presente ningún acceso usando ese índice. Los procesos de cargar estadísticas 'interesantes', calcular estimaciones de cardinalidad y producir un plan de ejecución terminado son actividades bastante independientes.

Eliminar el índice también eliminaría las estadísticas de índice asociadas, lo que puede afectar la calidad del plan la próxima vez que se vuelva a compilar la declaración. El índice estadísticas del pueden usarse en un cálculo de estimación de cardinalidad en el que se basa el plan final, incluso cuando el índice no está físicamente presente en el plan final.

Su DBA sabe sus cosas.

Nada de esto debe entenderse como que los índices aparentemente no utilizados nunca deben eliminarse. Simplemente digo que las preocupaciones de su DBA son válidas, y debe planificar el cambio con ellas en consecuencia, con las pruebas adecuadas y un plan de recuperación. En mi experiencia, el punto n. ° 1 es más probable que sea problemático que el n. ° 2, pero no tengo forma de saber si eso se aplica a su situación.