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 la création d'un index et la définition de plusieurs colonnes par rapport à un index par colonne que vous souhaitez indexer?.
Y a-t-il certaines raisons pour lesquelles l'une devrait être utilisée plutôt que l'autre?
Par exemple
Create NonClustered Index IX_IndexName On TableName
(Column1 Asc, Column2 Asc, Column3 Asc)
Versus
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)
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. En gros, cela aide vos données à être insérées à la fin de l'index et ne cause pas beaucoup de fractures disque IO et Page.
Deuxièmement, si vous créez d'autres index sur vos données et si elles sont construites intelligemment, elles seront réutilisées.
par exemple. imaginez que vous recherchez une table sur trois colonnes
état, comté, Zip.
Puis un index avec état, comté, Zip. sera utilisé dans ces trois recherches.
Si vous recherchez beaucoup par Zip seul, alors l'index ci-dessus ne sera pas utilisé (de toute façon par SQL Server), car Zip est la troisième partie de cet index et l'optimiseur de requêtes ne jugera pas cet index utile.
Vous pouvez ensuite créer un index sur Zip seul qui serait utilisé dans ce cas.
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 celles de votre groupe.
L'article aidera beaucoup. :-)
Oui. Je vous recommande de vérifier articles de Kimberly Tripp sur l'indexation .
Si un index "couvre", il n'est pas nécessaire d'utiliser autre chose que l'index. Dans SQL Server 2005, vous pouvez également ajouter à l'index des colonnes supplémentaires ne faisant pas partie de la clé, ce qui peut éliminer les détournements du 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 offrent différents schémas d'indexation.
Vous pouvez également utiliser l'assistant de réglage pour vous aider à déterminer quels index donneraient le meilleur résultat à une requête ou à une charge de travail donnée.
L'index multi-colonnes peut être utilisé pour les requêtes référençant tout les colonnes:
SELECT *
FROM TableName
WHERE Column1=1 AND Column2=2 AND Column3=3
Ceci peut être recherché directement en utilisant l'index multi-colonnes. D'autre part, un seul index de la colonne unique peut être utilisé (il devrait rechercher tous les enregistrements ayant Column1 = 1, puis cocher Column2 et Column3 dans chacun de ceux-ci).
Un élément qui semble avoir été oublié est celui des transformations d'étoiles. Intersection d'index les opérateurs résolvent le prédicat en calculant l'ensemble des lignes touchées par chacun des prédicats avant qu'une 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 déterminer les lignes à sélectionner par le calcul de l'intersection d'index. Les index sur les colonnes individuelles offrent la meilleure flexibilité pour cela.
Si vous avez des requêtes qui utilisent fréquemment un ensemble de colonnes relativement statique, la création d'un seul index couvrant les incluant toutes améliorera considérablement les performances.
En mettant plusieurs colonnes dans votre index, l'optimiseur n'aura à accéder directement à la table que si une colonne ne figure 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 simples est utile pour les opérations de recherche fréquemment trouvé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 utilisés. L'indexation est aussi instinctive que la science.