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 :

Principes

modifier

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 :
    1. tri fusion (merge join)
    2. hachage (hash join)
    3. boucle imbriquée (nested loop join)
    4. 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 LIKE ne sont pas remplaçables par des =.
  • S'assurer que les CURSOR (en) ne sont pas remplaçables.

Notes et références

modifier
  1. Serge Abiteboul, Sciences des données : de la logique du premier ordre à la Toile, Paris, Collège de France, 2012, 1458 p. (ISBN 978-2-722-60171-0, OCLC 910781670, lire en ligne)
  2. (en) Ken Henderson, The Guru's Guide to Transact-SQL, Addison-Wesley Professional, 23 février 2000 (lire en ligne)
  3. (en) Kevin Kline, SQL in a Nutshell : A Desktop Quick, O'Reilly Media, Inc., 2004 (lire en ligne)

Voir aussi

modifier

Sur les autres projets Wikimedia :

Articles connexes

modifier

Liens externes

modifier

📚 Artikel Terkait di Wikipedia

Karl Kunisch

plusieurs revues mathématiques, dont le SIAM Journal on Control and Optimization, le SIAM Journal on Numerical Analysis et le Journal of the European

Accumulateur thermique

Luca Constantin, Daniel Dragomir-Stanciu et Ionut Vasile Crismaru, « Optimization of Heat Exchange in a Heat Accumulator with Latent Heat Storage », Procedia

Liste de problèmes NP-complets

with unfixed variable locations · Ensemble computation · Microcode bit optimization Article détaillé : programmation informatique. Inequivalence of programs

Ivermectine

Jean-François Sutra et Anne Lespine, Ecotoxicity of antiparasitics: optimization of the use of pharmaceutical forms of ivermectin and its analogues, INRAE

Erol Gelenbe

checkpoints for programs with loops," Simul. Model. Pract. Theory 97 (2019)* E. Gelenbe and Y. Zhang. "Performance Optimization With Energy Packets," IEEE

Robert Ayres

lire en ligne) (en) Robert Ayres, « Toxic heavy metals: materials cycle optimization », Proceedings of the National Academy of Sciences, vol. 89, no 3,‎ 1er

Anna Nagurney

Products, avec Min Yu, Amir Masoumi et Ladimer Nagurney. Springer Briefs in Optimization. (en) Cet article est partiellement ou en totalité issu de l’article

Sakana AI

articles scientifiques. Ce système fonctionne en boucle ouverte (open-ended loop), c'est-à-dire selon un processus de recherche automatisé sans fin prédéfinie