Index multiples vs index multi-colonnes
Je suis d’accord avec Cade Roux.
Cet article devrait vous mettre sur la bonne voie :
Une chose à noter : les index cluster devraient avoir une clé unique (une colonne d’identité, je recommanderais) comme première colonne.
En gros, cela aide vos données à s’insérer à la fin de l’index et à ne pas causer beaucoup d’E/S disque et de fractionnements de pages.
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 recherchez dans une table sur trois colonnes :
state, county, zip.
-
vous recherchez parfois uniquement par state.
-
vous recherchez parfois par state et county.
-
vous recherchez fréquemment par state, county, zip.
Alors un index avec state, county, zip sera utilisé dans ces trois recherches.
Si vous recherchez souvent par zip seul, alors l’index ci-dessus ne sera pas utilisé (par SQL Server en tout cas) car zip est la troisième partie de cet index et l’optimiseur de requêtes ne considérera pas cet index comme utile.
Vous pourriez alors créer un index sur zip seul qui serait utilisé dans ce cas.
Au fait, nous pouvons tirer parti du fait qu’avec l’indexation multi-colonnes, la première colonne de l’index est toujours utilisable pour la recherche et lorsque vous recherchez uniquement par « state », c’est efficace mais pas aussi efficace qu’un index à colonne unique sur « state ».
Je suppose que la réponse que vous cherchez est que cela dépend des clauses WHERE de vos requêtes fréquemment utilisées et aussi de vos GROUP BY.
L’article vous aidera beaucoup. 