Question Index multiples vs index multi-colonnes


Je viens d'ajouter un index à une table dans SQL Server 2005 et cela m'a fait réfléchir. Quelle est la différence entre créer 1 index et définir plusieurs colonnes sur 1 index par colonne que vous souhaitez indexer?

Existe-t-il certaines raisons pour lesquelles l'un devrait être utilisé par rapport à l'autre?

Par exemple

Create NonClustered Index IX_IndexName On TableName
(Column1 Asc, Column2 Asc, Column3 Asc)

Contre

Create NonClustered Index IX_IndexName1 On TableName
(Column1 Asc)

Create NonClustered Index IX_IndexName2 On TableName
(Column2 Asc)

Create NonClustered Index IX_IndexName3 On TableName
(Column3 Asc)

494
2017-10-07 15:36


origine


Réponses:


je suis d'accord avec Cade Roux.

Cet article devrait vous mettre sur la bonne voie:

Une chose à noter, les index clusterisés devraient avoir une clé unique (une colonne d'identité que je recommanderais) comme première colonne. Fondamentalement, il aide vos données à insérer à la fin de l'index et ne cause pas beaucoup d'E / S disque et de divisions de page.

Deuxièmement, si vous créez d'autres index sur vos données et qu'ils sont construits intelligemment, ils seront réutilisés.

par exemple. imaginez que vous cherchez une table sur trois colonnes

état, comté, zip.

  • vous recherchez parfois par état seulement.
  • vous recherchez parfois par état et par comté.
  • vous recherchez fréquemment par état, comté, zip.

Puis un index avec état, comté, zip. sera utilisé dans ces trois recherches.

Si vous effectuez une recherche par zip assez souvent, l'index ci-dessus ne sera pas utilisé (par SQL Server de toute façon) car zip est la troisième partie de cet index et l'optimiseur de requêtes ne verra pas cet index comme utile.

Vous pourriez alors créer un index sur Zip seul qui serait utilisé dans cette instance.

Je suppose que la réponse que vous recherchez est que cela dépend de vos clauses where de vos requêtes fréquemment utilisées et de vos groupes.

L'article aidera beaucoup. :-)


239
2017-10-07 16:10



Oui. Je vous recommande de vérifier Les articles de Kimberly Tripp sur l'indexation.

Si un index est "couvrant", il est inutile d'utiliser autre chose que l'index. Dans SQL Server 2005, vous pouvez également ajouter à l'index des colonnes supplémentaires qui ne font pas partie de la clé, ce qui peut éliminer les déplacements vers le reste de la ligne.

Avoir plusieurs index, chacun sur une seule colonne peut signifier qu'un seul index est utilisé - vous devrez vous référer au plan d'exécution pour voir quels effets différents schémas d'indexation offrent.

Vous pouvez également utiliser l'assistant d'optimisation pour déterminer les index qui donneraient le meilleur rendement à une requête donnée ou à une charge de travail.


60
2017-10-07 15:41



L’index multi-colonnes peut être utilisé pour le référencement des requêtes tout Les colonnes:

SELECT *
FROM TableName
WHERE Column1=1 AND Column2=2 AND Column3=3

Cela peut être recherché directement à l'aide de l'index multi-colonnes. D'un autre côté, vous pouvez utiliser au plus l'un des index à une seule colonne (il devrait rechercher tous les enregistrements ayant Column1 = 1, puis vérifier Column2 et Column3 dans chacun de ceux-ci).


30
2017-10-07 15:46



Un élément qui semble avoir été manqué est la transformation en étoile. Index Intersection les opérateurs résolvent le prédicat en calculant l'ensemble des lignes touchées par chacun des prédicats avant que toute E / S ne soit effectuée sur la table de faits. Sur un schéma en étoile, vous indexez chaque clé de dimension individuelle et l'optimiseur de requête peut résoudre les lignes à sélectionner par le calcul d'intersection d'index. Les index sur les colonnes individuelles offrent la meilleure flexibilité pour cela.


11
2017-10-07 19:19



Si vous avez des requêtes qui utilisent fréquemment un ensemble de colonnes relativement statique, la création d'un seul index de couverture qui les inclut toutes améliore considérablement les performances.

En mettant plusieurs colonnes dans votre index, l'optimiseur n'aura besoin d'accéder directement à la table que si une colonne n'est pas dans l'index. Je les utilise beaucoup dans l'entreposage de données. L'inconvénient est que cela peut coûter très cher, surtout si les données sont très volatiles.

La création d'index sur des colonnes uniques est utile pour les opérations de recherche fréquemment rencontrées dans les systèmes OLTP.

Vous devriez vous demander pourquoi vous indexez les colonnes et comment elles seront utilisées. Exécuter des plans de requête et voir quand ils sont en cours d'accès. L'accord d'index est autant instinct que science.


5
2017-10-07 15:46



Le livre de Lahdenmaki et Leach "Conception de l'index des bases de données relationnelles et des optimiseurs" introduit un système trois étoiles pour évaluer l'adéquation d'un index à une requête.

  1. L'index gagne une étoile s'il place des lignes pertinentes adjacentes les unes aux autres
  2. une deuxième étoile si ses lignes sont triées dans l'ordre dont la requête a besoin
  3. une étoile finale si elle contient toutes les colonnes nécessaires à la requête

Créer des index multiples sur des colonnes, cette stratégie d'indexation se produit souvent lorsque les utilisateurs donnent des conseils vagues mais autoritaires tels que «créer des index sur les colonnes qui apparaissent dans la clause WHERE». Ce conseil est très faux. Il en résultera au mieux des index une étoile. Ces indices peuvent être de plusieurs ordres de grandeur plus lents que les index réellement optimaux. Parfois, lorsque vous ne pouvez pas concevoir un index trois étoiles, il est préférable d'ignorer la clause WHERE et de faire attention à l'ordre des lignes optimal ou de créer un index de couverture à la place.


0
2017-07-15 13:23