Trop d'index tue l'index?

Bonjour à tous,

Afin d'optimiser le temps de réponse de mes requêtes j'ai besoin de votre aide sur le meilleur moyen d'indexation d'une table (SQL Server 2005)

J'ai une table "Dossier" avec une trentaines de colonnes. Parmi elles, 17 clefs étrangères (de type INT avec des contraintes) où 10 d'entre elles acceptent 'NULL'

J'ai un écran de rechèrche multi-critères, qui génère, coté SQL, une requête Dynamique où dans la clause "WHERE" je peux avoir 2 ou plusieurs clefs étrangères.

Afin d'optimiser les performances, devrais-je créer un index pour chaque clef étrangère fréquemment utilisée ou bien le faire par paire, triplet...?

Est ce que le fait d'avoir plusieurs indexs qui référencent la même colonne (seule ou avec une autre colonne) est une approche plus efficace?

Merci pour votre aide.

Bonjour,

Citation:

---

Afin d'optimiser les performances, devrais-je créer un index pour chaque clef étrangère fréquemment utilisée ou bien le faire par paire, triplet...?

---

Malheureusement il n'y a pas de méthode directe d'optimisation : vous devez analyser les texte des requêtes qui utilisent cette table et adapter vos indexes (mono ou multi-colonnes) suivant les colonnes les plus fréquemment utilisées.

J'espère que vous utilisez la procédure stockée sp_executeSQL pour exécuter vos requêtes dynamiques ;)

Citation:

---

Est ce que le fait d'avoir plusieurs indexs qui référencent la même colonne (seule ou avec une autre colonne) est une approche plus efficace?

---

Non car pour toute mise à jour d'une colonne référencée par plusieurs indexes, il faut mettre tous ces indexes à jour ...

@++ ;)

Merci pour ces réponses,

Concernant les requêtes dynamiques mises en cause, elles sont développées par un sous-traitant d'un module de l'appli et je viens de voir qu'ils utilisent la commande EXECUTE au lieu de la procédure stockée sp_executeSQL!!!

n'ayant jamais utilisé les requêtes dynamiques, pour l'instant, je ne connais pas la différence entre les deux!

Merci d'avance.

L'instruction EXEC ne permet pas la réutilisation des plans de requêtes des chaînes de requête, alors que sp_executeSQL le permet puisqu'elle paramètre votre requête.
Si donc vous effectuez très souvent la même requête aux valeurs de paramètres près, le plan de requête généré lors de la première exécution de votre procédure stockée pourra être réutilisé, évitant ainsi le temps de compilation de la requête ;)

@++ ;)

Merci, intéressant à savoir!

Est ce que le plan de requête généré avec la SP "sp_executeSQL" est utilisable pour la même session uniquement ou bien pour tous les utilisateurs sur la même base de données?

Car effectivement la même requête avec presque les mêmes paramètres sera utilisée assez fréquemment par plusieurs utilisateurs (+- 1000 users) ?

Les plans de requête les plus fréquemment utilisés demeurent dans un cache que l'on appelle cache de procédures.
Ce cache demeurant en RAM, toutes les sessions y ont accès.

Il en va de même pour les données : les pages lues le plus souvent demeurent dans un cache que l'on appelle cache de données, et demeure de la même façon en RAM.

C'est pour cela qu'il est important, par exemple, de ne pas redémarrer le serveur qui héberge l'instance SQL Server, ou encore d'utiliser l'une de ces instructions

@++ ;)

Merci encore pour vos réponses, je vois plus claire maintenant ;)