J'ai utilisé un outil d'auto-index sur notre base de données MS SQL (j'ai modifié un script provenant de Microsoft qui examine les tables de statistiques d'index - Indexation automatique ). À partir des statistiques, j'ai maintenant une liste de recommandations pour les index à créer.

Édition: Les index décrits ci-dessus prennent des informations provenant du DMV qui vous indiquent ce que le moteur de base de données utiliserait pour les index s'ils étaient disponibles et les scripts prennent les recommandations Top x (par recherches, impact utilisateur, etc.) et les mettent dans un tableau.

(Editer ci-dessus, extrait en partie de la réponse de Larry Coleman ci-dessous afin de clarifier ce que font les scripts)

Comme je suis nouveau dans l’administration de base de données et que j’ai effectué une recherche rapide sur le réseau, je suis réticent à franchir le pas et ajouter aveuglément les index recommandés. Cependant, n'ayant pas d'expérience sur le terrain, je cherche des conseils sur la manière de déterminer si les recommandations sont nécessaires ou non.

Dois-je exécuter le Générateur de profils SQL ou faut-il mieux examiner le code qui interroge les tables? Et avez-vous un autre conseil?

J'utilise les scripts d'analyse d'index de Jason Strate (Old location) . Ils vous indiquent combien vos index existants sont utilisés ainsi que le nombre d'index manquants qui auraient été utilisés. En général, je n'ajoute pas d'index, à moins qu'ils ne représentent plus de 5 ou 10% des requêtes d'une table.

Mais le plus important est de s’assurer que l’application répond assez vite pour les utilisateurs.

Mise à jour: articles de blog sur l'analyse d'index de Jason Strate pour les nouveaux scripts (nouvel emplacement)

Double mise à jour: Ces jours-ci, j'utilise sp_BlitzIndex® lors de l'analyse d'index.

Il est important de comprendre quelques concepts et termes lorsqu’il s’agit d’index. Les recherches, les analyses et les recherches sont quelques-unes des façons dont les index seront utilisés dans des instructions select. La sélectivité des colonnes de clés est essentielle pour déterminer l'efficacité d'un index.

Une recherche se produit lorsque SQL Server Query Optimizer détermine que le meilleur moyen de rechercher les données demandées consiste à analyser une plage au sein d'un index. Les recherches se produisent généralement lorsqu'une requête est "couverte" par un index, ce qui signifie que les prédicats de recherche se trouvent dans la clé d'index et que les colonnes affichées sont dans la clé ou incluses. Une analyse se produit lorsque SQL Server Query Optimizer détermine que le meilleur moyen de rechercher les données consiste à analyser l'intégralité de l'index, puis à filtrer les résultats. Une recherche a généralement lieu lorsqu'un index n'inclut pas toutes les colonnes demandées, que ce soit dans la clé d'index ou dans les colonnes incluses. L'optimiseur de requête utilisera ensuite la clé en cluster (par rapport à un index en cluster) ou le RID (par rapport à un segment de mémoire) pour "rechercher" les autres colonnes demandées.

En règle générale, les opérations de recherche sont plus efficaces que les analyses, en raison de l'interrogation physique d'un ensemble de données plus petit. Il existe des situations où ce n'est pas le cas, par exemple un très petit jeu de données initial, mais cela dépasse le cadre de votre question.

Vous avez maintenant demandé comment déterminer l’efficacité d’un indice et vous devez garder quelques points à l’esprit. Les colonnes de clé d'un index clusterisé sont appelées clé de clustering. C’est ainsi que les enregistrements sont rendus uniques dans le contexte d’un index clusterisé. Tous les index non clusterisés incluront la clé en cluster par défaut, afin de pouvoir effectuer des recherches si nécessaire. Tous les index seront insérés, mis à jour ou supprimés pour chaque instruction DML respective. Cela étant dit, il est préférable d'équilibrer les gains de performances dans les instructions select avec les succès obtenus dans les instructions d'insertion, de suppression et de mise à jour.

Afin de déterminer l'efficacité d'un index, vous devez déterminer la sélectivité de vos clés d'index. La sélectivité peut être définie en tant que pourcentage d'enregistrements distincts par rapport au nombre total d'enregistrements. Si j'ai une table [personne] avec 100 enregistrements au total et que la colonne [prénom] contient 90 valeurs distinctes, nous pouvons dire que la colonne [prénom] est sélective à 90%. Plus la sélectivité est élevée, plus la clé d'index est efficace. En gardant à l'esprit la sélectivité, il est préférable de placer les colonnes les plus sélectives en premier dans la clé d'index. En utilisant mon exemple précédent [personne], que se passe-t-il si nous avions une colonne [nom_de_vivre] qui était sélective à 95%? Nous voudrions créer un index avec [nom], [prénom] comme clé d'index.

Je sais que la réponse était un peu longue, mais il y a vraiment beaucoup de choses qui déterminent l'efficacité d'un indice, et vous devez peser beaucoup de choses pour gagner en performance.

J'ai récemment découvert un fantastique script gratuit chez BrentOzar Unltd http://www.brentozar.com/blitzindex/

Cela fait une bonne analyse des index existants, de leur fréquence d'utilisation et de la fréquence à laquelle le moteur de recherche recherche un index qui n'existe pas.

Ses conseils sont généralement bons. Parfois, les idées sont un peu trop suggestives. J'ai généralement fait ce qui suit jusqu'à présent:

• Les index supprimés qui n'ont JAMAIS été lus (ou peut-être moins de 50 fois par mois).
• Ajout des index les plus évidents sur les clés étrangères et les champs que je sais que nous utilisons beaucoup.

Je n'ai pas ajouté tous les index recommandés et je suis revenu une semaine plus tard pour constater qu'ils ne sont plus recommandés, car le moteur de requête utilise plutôt certains des nouveaux index!

En règle générale, vous devriez éviter les index sur:

• Très petites tables (moins de 50 à 200 enregistrements): le moteur de requête est souvent plus rapide s'il analyse la table plutôt que de charger l'index, de le lire, de le traiter, etc.
• Évitez les index sur les colonnes avec une faible cardinalité ( http://en.wikipedia.org/wiki/Cardinality_(SQL_statements) ) sur la première colonne mentionnée. Par exemple, l'indexation d'un champ de genre (M / F) est très peu utile, il est tout aussi pratique de parcourir le tableau et de trouver les ~ 50% qui correspondent. S'il est répertorié après quelque chose de plus spécifique dans l'index (par exemple, [date de naissance, sexe]), c'est mieux - vous pouvez souhaiter que tous les hommes naissent au cours d'une période donnée.

Les index clusterisés sont bons - normalement, ils sont basés sur votre clé primaire. Ils aident le moteur de base de données à mettre les données sur le disque en bon ordre. Il est essentiel de comprendre cela pour les tables les plus grandes, car un bon index clusterisé réduit souvent l'espace occupé par la table.

J'ai réduit certaines tables de 900 Mo à 400 Mo, simplement parce qu'elles étaient auparavant des tas non structurés. http://msdn.microsoft.com/en-us/library/aa933131(v=sql.80).aspx

Réorganiser / Reconstruire

Vous devriez chercher à vérifier les index fragmentés. Un peu de fragmentation c'est bien, ne soyez pas obsédés! http://technet.microsoft.com/en-us/library/ms189858.aspx Découvrez la différence entre réorganiser et reconstruire!

Revoir régulièrement

Les requêtes changent, les volumes de données changent, de nouvelles fonctionnalités sont ajoutées, les anciennes supprimées. Vous devriez les regarder une fois par mois (ou plus souvent si vous avez de gros volumes) et chercher où vous pouvez aider la base de données!

Combien

Dans une vidéo récente, Brent recommande (en règle générale) de ne pas placer plus de 5 index sur une table avec beaucoup d'écriture (par exemple, une commande), et pas plus de 10 s'il est lu beaucoup plus que d'écritures (par exemple, une table de journalisation pour l'analyse) http: / /www.youtube.com/watch?v=gOsflkQkHjg

Global

Ça dépend!

Votre kilométrage varie selon la base de données. Couvrez l'évident (nom de l'employé, date de la commande, etc.) sur vos tables (actuelles / futures) plus grandes. Surveillez, révisez et ajustez si nécessaire. Cela devrait faire partie de votre liste de contrôle de routine lorsque vous gérez vos bases de données :)

J'espère que cela t'aides!

Normalement, il faut disposer d’une charge de travail spécifique (requêtes) et tester soigneusement l’impact de chaque nouvel index sur la charge de travail. Ce processus itératif doit toujours inclure une analyse minutieuse des plans d’exécution, qui permettrait de déterminer les index utilisés. Le sujet de l'analyse d'une requête est long et il convient de commencer par le chapitre dédié à MSDN intitulé Analyser une requête .

Parfois, lorsque la charge de travail est trop complexe ou que les connaissances en matière de conception de base de données sont incomplètes, utilisez l’Assistant Paramétrage du moteur de base de données , qui effectue une analyse automatique de votre charge de travail et propose des index. Bien entendu, les propositions doivent être soigneusement analysées et l’impact doit être mesuré immédiatement.

Donc, si vous suivez mon idée, ajouter un index et mesurer son impact n’est en réalité qu’un cas de test A / B : vous exécutez votre charge de travail sans l’index comme ligne de base, puis vous l’exécutez avec l’index, vous mesurez et comparez avec la ligne de base puis décidez, en fonction des mesures observées et mesurées, si l’impact est bénéfique. La charge de travail correspond mieux à une suite de tests de bonne qualité, mais il peut également s'agir d'une relecture d'une charge de travail capturée, voir Comment: relire un fichier de trace .

Une réponse plus synthétique consiste à examiner la sys.dm_db_index_usage_statsvue et à voir comment les indices sont utilisés, mais il s'agit généralement d'une approche permettant d'effectuer une analyse sur site avec une charge de travail inconnue (un consultant appelé à l'aide commencerait probablement par cela).

À partir de SQL 2005, SQL Server contient des applications DMV qui vous indiquent ce que le moteur de base de données utiliserait pour les index s’ils étaient disponibles. Les vues peuvent vous indiquer quelles colonnes doivent être des colonnes clés, quelles colonnes doivent être incluses et, plus important encore, combien de fois l'index aurait été utilisé.

Une bonne approche serait de trier la requête d'index manquante par nombre de recherches et d'envisager d'ajouter les premiers index en premier.

^{Voir aussi: les documents officiels MS DMV}

Cela dépend de la façon dont cette table est utilisée. par exemple, disons que j'ai une table qui est lue de nombreuses fois mais les mises à jour et les insertions sont rares. De plus, j'interroge toujours la table sur une colonne de clé étrangère. Il est judicieux de créer un index (sans cluster) sur cette clé étrangère pour accélérer les requêtes de lecture. Mais l'inconvénient est que votre insertion, la mise à jour deviendra lente.

Il existe peu de requêtes statistiques qui indiquent combien de temps prennent les requêtes. Commencez avec les plus lents. Si le prédicat de requête n'a pas d'index, sa création vous aidera.