Optimisation de requête
Cet article est une ébauche concernant l’informatique.
Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.
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
[modifier | modifier le code]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
[modifier | modifier le code]- Serge Abiteboul, Sciences des données : de la logique du premier ordre à la Toile, Paris, Collège de France, , 1458 p. (ISBN 978-2-722-60171-0, OCLC 910781670, lire en ligne)
- (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).
