Suppression des index inutilisés - Évaluation des dangers inattendus

Nous avons une très grande base de données avec des centaines d'index inutilisés selon les statistiques DMV, qui se sont accumulés depuis le dernier redémarrage du serveur en juillet. L'un de nos administrateurs de base de données a émis les avertissements suivants, qui n'ont aucun sens pour moi:

1. Avant de supprimer un index, nous devons nous assurer qu'il n'applique pas une contrainte d'unicité, car l'optimiseur de requête peut avoir besoin de cet index pour exister.
2. Chaque fois qu'un index est créé, les statistiques liées à cet index sont également créées dans SQL Server. Une requête n'utilise peut-être pas l'index, mais elle utilise peut-être ses statistiques. Nous pouvons donc rencontrer une situation, après la suppression d'un index, les performances d'une requête particulière deviennent vraiment mauvaises. SQL Server ne conserve pas les statistiques d'utilisation des statistiques. Bien que la fonctionnalité «Création automatique de statistiques» soit activée dans notre base de données, je ne sais pas quels paramètres doivent être respectés en interne avant que l'optimiseur de requête crée les statistiques manquantes.

En ce qui concerne # 1, il me semble que SQL Server ferait réellement une recherche sur l'index pour déterminer l'unicité avant qu'une insertion / mise à jour soit effectuée, et par conséquent, l'index ne s'afficherait pas comme n'étant pas utilisé.

Concernant # 2, est-ce vraiment possible?

Soit dit en passant, quand je dis qu'un index n'est pas utilisé, je veux dire pas de recherche ni d'analyse.

Les préoccupations de votre administrateur de base de données sont valables.

En ce qui concerne # 1, il me semble que SQL Server ferait réellement une recherche sur l'index pour déterminer l'unicité avant qu'une insertion / mise à jour soit effectuée, et par conséquent, l'index ne s'afficherait pas comme n'étant pas utilisé.

La garantie d'unicité peut être utilisée par l'optimiseur pour décider quelles transformations logiques ou opérations physiques peuvent être utilisées pour obtenir des résultats corrects. Le fait que l'optimiseur s'appuie sur une garantie d'unicité pour, par exemple, transformer une agrégation ou choisir une jointure de fusion un-à-plusieurs, ne sera pas reflété dans les statistiques d'utilisation de l'index, sauf si l'index est également physiquement accessible dans le plan d'exécution final. . Il faut donc être très prudent en supprimant (ou en désactivant) tout index ou contrainte unique.

Concernant # 2, est-ce vraiment possible?

Oui, il est possible que l'optimiseur utilise des statistiques associées à un index sans que le plan d'exécution final n'ait accès à cet index. Les processus de chargement de statistiques «intéressantes», de calcul d'estimations de cardinalité et de production d'un plan d'exécution fini sont des activités assez indépendantes.

La suppression de l'index supprimerait également les statistiques d'index associées, ce qui pourrait affecter la qualité du plan lors de la recompilation de l'instruction. Les statistiques d' index peuvent être utilisées dans un calcul d'estimation de cardinalité sur lequel le plan final s'appuie, même lorsque l'indice n'est pas physiquement présent dans le plan final.

Votre DBA connaît ses affaires.

Rien de tout cela ne doit être interprété comme signifiant que les index apparemment inutilisés ne doivent jamais être supprimés. Je dis simplement que les préoccupations de votre administrateur de base de données sont valables et que vous devez planifier le changement avec eux en conséquence, avec des tests appropriés et un plan de récupération. D'après mon expérience, le point n ° 1 est plus susceptible d'être problématique que le n ° 2, mais je n'ai aucun moyen de savoir si cela s'applique à votre situation.