Discussion :

[SetaSensei]

Bonjour,

Voici mon problème : j'ai une procédure stockée assez lourde qui est exécutée très souvent. La partie la plus lourde possède 5 joins différents (inner et left) que j'essaye ne ce moment d'optimiser au maximum.

Dans la clause where de ma requête, j'ai 3 conditions sur une même table, ces 3 conditions sont sur des colonnes de type Bit nullables.
J'ai créé un index sur ces 3 colonnes, sans index j'avais un table scan qui prendait 30% de ma requête. Avec cet index (qui couvre toutes les conditions de tri et de sélection pour cette table) j'obtiens maintenant dans le plan d'exécution un index scan qui prend 23 % plus un bookmark lookup à 9% ...

Si besoin je peux vous mettre la requête en entier mais ce n'est pas forcément parlant

Merci !

[kagemaru]

Idéalement, il faudrait poster toutes les infos ( le plan_text, la sortie du set statistics io, la requête et les index sur les tables )

merci

[SQLpro]

Le plan de requête n'a pas grand intérêt et les pourcentages affichés ne sont qu'une inication. Sans cooroboration ils ne veuelent strictement rien dire.

La mesure de l'efficacité d'un index se voit en nombre d'IO affiné en temps CPU.

Pour cela affichez les statistiques de lecture des pages et de consommation de processeur dans l'analyseur de requête et comparez avant et après indexation.

Inspirez vous de l'article que j'ai écrit à ce sujet :
http://www.sqlspot.com/INDEXATION-un...l-exemple.html

A +