Bonjour,
 
J'ai une procédure stockée qui comporte un grand nombre de requêtes SQL. La grande majorité de celles-ci se déroule très rapidement (qq ms), mais 2 d'entre elles sont très longues (500s pour une, >1000s pour l'autre) sans que je comprenne vraiment pourquoi (elles sont en tout point similaire aux autres)
 
J'ai activé la trace sur l'analyseur de requêtes et sur le générateur de profil. Le premier m'indique ~200ms pour les deux requêtes en question alors que le second indique env. 500 000 ou 1 000 000 ms.
 
Quelqu'un saurait-il à quoi cette différence est dûe ?
Quelqu'un aurait-il une explication quand à la longueur de ces deux requêtes particulières ?
 
Voici les requêtes en question :
 

 
Je précise que
Table1_ID est la clé primaire de la Table1
@T est une variable table
Colonne2 est une clé étrangère de la Table2
 
Si vous avez besoin de plus d'informations, n'hésitez pas !
 
 
Merci d'avance

déjà, vire ton IN et remplace le par un EXISTS avec une jointure dans la sous-requête, ce sera bien plus rapide

Donne nous le nombre de lignes dans chaque table, pour commencer ...
 
Quant au IN / EXISTS, ça dépend du SGBD, Oracle par exemple s'en fout un peu, il choisit le meilleur plan d'exécution, que l'on mette IN ou EXISTS ... peut-être que ça a une importance pour SQL Server, je sais pas.

et au niveau du plan d'exécution?
les données dans le where sont exactement du même type?

Je parie qu'avec des index bien placés, ça irait plus vite.

A la seule différence près qu'un IN, de mémoire, ne peux pas dépasser 8000 éléments sous Oracle (du moins, jusqu'à la version 9i incluse) même si c'est une sous-requête, alors que le EXISTS n'a pas de limite en nombre d'éléments.
 
C'est à cause de cette limitation que j'ai découvert le mot clé EXISTS, dont sur le coup, je suis sûr de moi

Quand à la diff de performances, peut-être que ça vient d'une réécriture du moteur dans les versions > 9i ou alors d'un paramètrage spécifique, mais moi, sous Oracle autant qu'avec n'importe quel SGBD, j'ai toujours divisé au moins par 5 les temps d'éxécution avec des EXISTS par rapport à IN

Sous Oracle, y a en effet pas mal de paramètre qui vont faire qu'à partir de versions récentes, et suivant le mode de l'optimiseur (cost based ou RULE), écrire IN ou EXISTS aura peu d'importance.
 
La limitation à 8000 élément dans une sous-requête IN, j'y crois pas trop avec la 9i ... faudrait tester
 
Le IN est le EXISTS ne sont pas strictement équivalents d'ailleurs, que ce soit niveau interprétation par l'optimiseur, mais aussi niveau résultat, la gestion des NULL n'est pas la même.
 
edit: plus d'infos ici :
 
http://asktom.oracle.com/pls/ask/f [...] 3229842074

Avec ce genre de query, il peut y avoir un rollback segment qui se remplit plus qu'à l'habitude, et si le tablespace est sous-dimensionné (ce que j'ai vu plusieurs fois), alors cela peut causer des ralentissements, ou même des erreurs d'exécution. Il faudrait qu'un DBA vous assiste pour régler ce problème de performance.