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 :
    1. tri fusion (merge join)
    2. hashage (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
  1. Sciences des données : De la logique du premier ordre à la Toile, Serge Abiteboul
  2. (en) Ken Henderson, The Guru's Guide to Transact-SQL, Addison-Wesley Professional, (lire en ligne)
  3. (en) Kevin Kline, SQL in a Nutshell : A Desktop Quick, O'Reilly Media, Inc., (lire en ligne)

Voir aussi

Articles connexes

Liens externes
  • Portail des bases de données
Cet article est issu de Wikipedia. Le texte est sous licence Creative Commons - Attribution - Partage dans les Mêmes. Des conditions supplémentaires peuvent s'appliquer aux fichiers multimédias.