Optimisation de requĂȘte
L'optimisation de requĂȘte est une opĂ©ration dans laquelle plusieurs plans d'exĂ©cution[1] d'une requĂȘte SQL sont examinĂ©s pour en sĂ©lectionner le meilleur.
L'estimation de leurs coûts dépend du temps d'exécution et du nombre de ressources utilisées pour y parvenir, elle se mesure en entrées-sorties. Typiquement les ressources coûteuses sont l'utilisation du processeur, la taille et la durée des tampons sur le disque dur, et les connexions entre les unités du parallélisme. Plusieurs SGBD comme Oracle et MySQL possÚdent des fonctions permettant d'effectuer ces calculs, via un optimiseur.
Il existe deux types d'optimisation :
- Le plan d'exécution logique (PEL), qui dépend de l'algÚbre relationnelle.
- Le plan d'exécution physique (PEP) qui tient compte des index et de la taille des données.
Principes
D'une maniĂšre gĂ©nĂ©rale, il convient d'effectuer par prioritĂ© dĂ©croissante dans le langage de requĂȘte :
- Les sélections, afin de réduire le plus grand nombre de données en mémoire. Dans la mesure du possible il faut éviter les wildcards (*) qui engendrent plus de transfert d'information en réseau (ex : ID ou dates de mises à jour inutiles).
- Les projections, toujours pour diminuer la taille des données.
- Les tris, pour accélérer les jointures.
- Les jointures. Les différents plans d'exécution examinés sont constitués des différents chemins d'accÚs (ex : accÚs aux index primaires et secondaires) et de la variété des techniques de jointure selon les hints :
- tri fusion (merge join)
- hashage (hash join)
- boucle imbriquée (nested loop join)
- produit (product join).
De mĂȘme, si l'ordre des conditions dans le WHERE ne modifie jamais le rĂ©sultat obtenu[2], il peut en revanche avoir un impact important sur les performances[3]. En effet, il est prĂ©fĂ©rable de :
- Placer les conditions qui filtrent le plus d'enregistrements avant les autres (cela nécessite en général de connaitre la taille courante des tables).
- Vérifier l'emploi du mot clé
BETWEEN, qui peut consommer plus de ressources en allant chercher des octets fragmentés sur le disque, qu'un parcours séquentiel de table. - S'assurer que les
LIKEne sont pas remplaçables par des=. - S'assurer que les
CURSOR(en) ne sont pas remplaçables.
Notes et références
- Sciences des données : De la logique du premier ordre à la Toile, Serge Abiteboul
- (en) Ken Henderson, The Guru's Guide to Transact-SQL, Addison-Wesley Professional, (lire en ligne)
- (en) Kevin Kline, SQL in a Nutshell : A Desktop Quick, O'Reilly Media, Inc., (lire en ligne)
- (en) Cet article est partiellement ou en totalitĂ© issu de lâarticle de WikipĂ©dia en anglais intitulĂ© « Query optimization » (voir la liste des auteurs).