Est-il OK d'ajouter aveuglément des index manquants?

J'utilise souvent SSMS pour tester mes procédures stockées lentes pour les index manquants. Chaque fois que je vois un "Index manquant (Impact xxx)", ma réaction est de créer le nouvel index. Il en résulte une requête plus rapide à chaque fois que je sache.

Une raison pour laquelle je ne devrais pas continuer à faire ça?

De nombreuses raisons.

L'un des plus importants auquel je puisse penser est que les DMV d'index manquants ne prennent pas en compte les index existants.

Exemple:

Vous avez une table avec ColA, ColB, ColC.

Vous avez actuellement un index sur ColA. L'index DMV manquant vous proposera d'ajouter un index (ColA, ColB). Cela peut être correct, mais la chose intelligente à faire est d'ajouter ColBune deuxième clé sur l'index existant. Sinon, vous avez une couverture en double et un espace et des frais généraux gaspillés.

De même, si vous avez un index ColB INCLUDE (ColA), il peut suggérer un index ColB INCLUDE (ColC). Encore une fois, la chose intelligente à faire est d'ajouter ColCà la liste d'inclusion dans l'index existant.

Les index suggérés ont une vue extrêmement étroite - ils ne regardent qu'une seule requête, ou une seule opération dans une seule requête. Ils ne prennent pas en compte ce qui existe déjà ou vos autres modèles de requête.

Vous avez toujours besoin d'un être humain intelligent pour analyser la stratégie globale d'indexation et vous assurer que la structure de votre index est efficace et cohérente.

S'il n'y avait aucun problème à simplement ajouter tous les index suggérés, il ne serait même pas nécessaire de les suggérer - ils seraient implémentés automatiquement.

Je recommande une utilisation prudente de cette technique de réglage car j'ai trouvé que les suggestions d'index manquantes apparaissant dans les plans de requête étaient toujours moins fiables car les requêtes et les schémas de base de données devenaient progressivement plus complexes. Cela est dû à diverses raisons dans mon expérience:

1) L '"amélioration en pourcentage" peut être très éloignée pour tous, sauf les requêtes les plus simples / les index les plus évidents, après tout, il ne s'agit que d'une estimation et ne découle pas des coûts réels encourus ou des nombres de lignes réels lors de l'exécution de la requête. J'ai vu les coûts des requêtes augmenter après la mise en œuvre d'un index suggéré, ou il n'est même pas utilisé et le plan reste le même.

2) Le plan de requête lui-même n'est pas optimal, soit en raison de la construction de la requête (jointures et clause where non optimisée, etc.), soit les estimations du nombre de lignes sont fausses en raison de statistiques manquantes / obsolètes. L'indexation vers un plan de requête brutalement mauvais est souvent au mieux une solution de pansement avec seulement une amélioration incrémentielle des performances.

3) Vous pourriez ne pas voir l'image entière. Cela est particulièrement vrai lorsque vous utilisez uniquement le plan graphique et que vous ne visualisez pas le XML pour voir si plusieurs index manquants ont été suggérés. Celui qui apparaît en premier dans le plan graphique n'est pas nécessairement celui qui a le plus d'impact sur la requête.

4) J'ai également rencontré de nombreux exemples de nouveaux index suggérés lors de la modification de l'index existant. Voir les autres réponses ici concernant ce point, elles sont parfaites, pas besoin que j'élabore davantage.

J'utilise uniquement les suggestions d'index manquantes comme point de départ lorsque je travaille avec une requête / un environnement inconnu pour voir où approfondir. J'ai obtenu de meilleurs résultats en regardant les opérateurs dans le plan (principalement les recherches / analyses / jointures) et en vérifiant l'info-bulle ou la fenêtre des propriétés pour voir quelles colonnes sont impliquées et en utilisant cela pour déterminer les candidats d'index à tester pour l'amélioration.

Il y a un tas de raisons, principalement - savoir comment les index fonctionnent et sont stockés - vous créerez toujours un index meilleur, ou du moins - pas pire, que les suggestions SSMS