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


21

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?


1
pouvez-vous me dire d'où je peux obtenir cette fonctionnalité d'index manquante.
Ali Raza Iftikhar

Réponses:


27

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 vois, c'est peut-être la raison pour laquelle j'ai l'impression d'avoir un bazillion d'index. Je suppose que je devrais essayer de mieux comprendre ces plans d'explication et de comprendre les index manuellement.
OO

Si vous utilisez Google duplicate index scriptsou quelque chose de similaire, il existe de nombreuses ressources pour retrouver ces informations. Je gère la plupart de mes propres index et j'en connais un peu mais je trouve toujours des dupes de temps en temps.
JNK

"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." +1! En tant que consultant, j'ai eu toutes sortes de clients dans toutes sortes de situations. Parfois, je reçois ces clients parce qu'ils ont beaucoup trop d'index (et les mauvais, les redondants, etc.) - tous suggérés par le conseiller de réglage du moteur de base de données.
Mike Walsh

@JNK - Je vais le faire.
OO

2
Grand point - les index qui se chevauchent est certainement la chose la plus importante à surveiller ici. Et bien sûr, plus vous avez d'index, plus l'insertion devient lente, plus le succès de la maintenabilité (ajout de complexité), etc.
Jeff Atwood

8

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.


2

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

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.