Je suppose également que vous utilisez Oracle. Et je vous recommande également de consulter la page Web du plan d'explication, pour commencer. Il y a beaucoup à optimiser, mais cela peut être appris.
Voici quelques conseils :
Premièrement, lorsque quelqu'un vous demande d'optimiser, il recherche presque toujours des performances acceptables plutôt que des performances ultimes. Si vous pouvez réduire le temps d'exécution d'une requête de 3 minutes à 3 secondes, n'hésitez pas à le réduire à 2 secondes, jusqu'à ce qu'on vous le demande.
Deuxièmement, effectuez une vérification rapide pour vous assurer que les requêtes que vous optimisez sont logiquement correctes. Cela semble absurde, mais je ne peux pas vous dire le nombre de fois où l'on m'a demandé conseil sur une requête lente, seulement pour découvrir qu'elle donnait parfois de mauvaises réponses ! Et il s'avère que le débogage de la requête s'est souvent avéré également l'accélérer.
En particulier, recherchez l'expression "Cartesian Join" dans le plan d'explication. Si vous le voyez là, il y a de fortes chances que vous ayez trouvé une jointure cartésienne involontaire. Le modèle habituel d'une jointure cartésienne involontaire est que la clause FROM répertorie les tables séparées par des virgules et que les conditions de jointure se trouvent dans la clause WHERE. Sauf qu'il manque une des conditions de jointure, si bien qu'Oracle n'a d'autre choix que d'effectuer une jointure cartésienne. Avec de grandes tables, c'est un désastre de performance.
Il est possible de voir une jointure cartésienne dans le plan d'explication où la requête est logiquement correcte, mais je l'associe aux anciennes versions d'Oracle.
Recherchez également l'index composé inutilisé. Si la première colonne d'un index composé n'est pas utilisée dans la requête, Oracle peut utiliser l'index de manière inefficace, voire pas du tout. Laissez-moi vous donner un exemple :
La requête était :
select * from customers
where
State = @State
and ZipCode = @ZipCode
(Le SGBD n'était pas Oracle, donc la syntaxe était différente, et j'ai oublié la syntaxe d'origine).
Un rapide coup d'œil aux index a révélé un index sur les clients avec les colonnes (pays, état, code postal) dans cet ordre. J'ai changé la requête en lecture
select * from customers
where Country = @Country
and State = @State
and ZipCode = @ZipCode
et maintenant, il s'est exécuté en environ 6 secondes au lieu d'environ 6 minutes, car l'optimiseur a pu utiliser l'index à bon escient. J'ai demandé aux programmeurs d'application pourquoi ils avaient omis le pays des critères, et ce fut leur réponse :ils savaient que toutes les adresses avaient un pays égal à "États-Unis". Ils ont donc pensé qu'ils pouvaient accélérer la requête en omettant ce critère !
Malheureusement, optimiser la récupération de la base de données n'est pas vraiment la même chose que gagner des microsecondes sur le temps de calcul. Cela implique de comprendre la conception de la base de données, en particulier les index, et au moins une vue d'ensemble de la façon dont l'optimiseur fait son travail.
Vous obtenez généralement de meilleurs résultats avec l'optimiseur lorsque vous apprenez à collaborer avec lui au lieu d'essayer de le déjouer.
Bonne chance pour accélérer l'optimisation !
