Je suis d'accord avec Cade Roux.
Cet article devrait vous mettre sur la bonne voie :
- Index dans SQL Server 2005/2008 :bonnes pratiques, partie 1
- Index dans SQL Server 2005/2008 - Partie 2 - Composants internes
Une chose à noter, les index clusterisés doivent avoir une clé unique (une colonne d'identité que je recommanderais) en tant que première colonne. P>
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 un tableau sur trois colonnes
état, comté, code postal.
- vous effectuez parfois une recherche uniquement par état.
- vous effectuez parfois une recherche par État et comté.
- vous effectuez fréquemment des recherches par État, comté, code postal.
Puis un index avec l'état, le comté, le code postal. sera utilisé dans ces trois recherches.
Si vous recherchez souvent par zip seul, 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ête ne verra pas cet index comme utile.
Vous pourriez alors créer un index sur Zip seul qui serait utilisé dans ce cas.
Soit dit en passant, nous pouvons tirer parti du fait qu'avec l'indexation multi-colonnes, la première colonne d'index est toujours utilisable pour la recherche et lorsque vous recherchez uniquement par 'état', elle est efficace mais pas aussi efficace que l'index à colonne unique sur 'état '
Je suppose que la réponse que vous cherchez est que cela dépend de vos clauses where de vos requêtes fréquemment utilisées et aussi de votre group by.
L'article aidera beaucoup. :-)
