Discussion :

[dens19]

Bonjour à tous,

Je travaille actuellement sur une base de données SQL SERVER 2000, et j'ai remarqué que dans certaines tables des index non clustered ont été créés sur la premiére colonne de l'index clustered.

Exemple pour la table TEST qui contient 5 colonnes A, B, C, D, E
Index clustered = A, B, C
Index non clustered = A

Y'a-t'il un quelconque intérêt à redéfinir un index non clustered sur la colonne A (à part de perdre de l'espace disque !!!!) ? Après avoir lu pas mal de documentations dessus il me semble que non puisqu'arrivé au noeud feuille d'un index non clustered, la clé de l'index clustered est trouvée (c'est l'équivalent d'un double seek d'index). Néanmoins j'aurais souhaité avoir votre avis sur ce sujet.

Cdlt.

[SQLpro]

cela se discute car un index sur 3 colonnes est plus de 3 fois plus gourmand qu'un index sur 2 colonnes, donc 3 fois moins rapide. il n'est donc pas toujours stupide de laisser ces index que l'on dit "superposés"...

A +

[dens19]

Merci de votre réponse.

Mais lors d'une recherche par index non clustered n'y a-t'il pas toujours une recherche dans l'index clustered aprés ?

Pour l'instant, après avoir tracé toutes les requêtes que j'ai vu passer sur 2 tables (c'est long !!!!) puis analysé le plan d'exécution de ces requêtes, toutes utilisent le seek index sur l'index clustered !!!! Dans ce cas je ne vois pas trop l'intérêt de garder l'index non-clustered, qu'en pensez-vous ?

[SQLpro]

Mais lors d'une recherche par index non clustered n'y a-t'il pas toujours une recherche dans l'index clustered aprés ?

Tout dépend si l'index est couvrant ou non pour la requête. Vous pouvez auditer son utilisation à l'aide de DMV.
Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/.cours/quoi-indexer/

A +