Plan de requêtes et optimiseur (2)

mettant tantôt la colonne en premier, tantôt la valeur. Dans ces deux cas, cela provoquera deux mises en cache, deux plans de requêtes… Avec la conséquence que le cache se saturera plus vite, et comme il sera plus encombré, il vieillira plus vite et ces éléments sortiront donc du cache plus rapidement en vertu de la fameuse Loi LRU… Maintenant que se passe t-il si la requête n’est pas trouvée dans le cache des procédures ?

Il convient au moteur relationnel de calculer un plan de requêtes et le meilleur possible ! Pour cela, la technique est simple, mais très raffinée. Le moteur est censé évaluer toutes les combinaisons possibles pour lire, traiter les données et enchaîner les différentes étapes aboutissant à la résolution de la requête. Mais comme la combinatoire peut rapidement devenir gigantesque, le programme qui calcule le plan de requêtes doit faire des impasses sur des solutions à priori peu rentables. Pour cela, il commence par évaluer la façon d’attaquer la lecture des données: peut-il se servir d’un index ou doit-il lire la table ? L’utilisation de l’index peut-elle mettre en oeuvre un algorithme de recherche ou est-il condamné à lire séquentiellement toutes les données ?

La réponse à ces interrogations se trouve dans les statistiques afférentes aux index, car derrière chaque index il y a des statistiques qui permettent d’estimer le volume de données qui va être manipulé. Cela se calcule en fonction de la valeur du paramètre, et de la dispersion des données dans l’index ou la table, le but étant de lire le moins possible de données dès le départ. A présent que l’on connaît la façon d’attaquer les données, on peut ensuite estimer la façon de les traiter. Ainsi, une jointure utilisera tel ou tel algorithme ( tri fusion, boucle imbriquée, clef de hachage… ) en fonction des volumes respectifs des données à mettre en relation et de la cardinalité [3] de la jointure. Même avec toutes ces impasses, le temps de calcul du plan de requêtes peut vite devenir très long et par exemple conduire à une situation absurde où le calcul du plan optimal prend plus de temps que le traitement de la requête.

C’est pourquoi l’optimiseur, car c’est son nom, utilise un algorithme de backtracking et une fenêtre de temps. Le backtracking est un moyen efficace d’explorer un arbre de combinaison probable en évaluant progressivement les branches à chaque bifurcation. Cela permet de s’arrêter dès que la descente dans une branche revêt un coup supérieur au meilleur plan déjà calculé. La fenêtre de temps, car il serait absurde que l’établissement du plan ne dure trop longtemps. Ainsi, l’optimiseur ne calcule pas systématiquement le plan optimal, mais un plan de requêtes qu’il a jugé le moins coûteux compte tenu de différentes contraintes préalables.

Bien entendu, on peut forcer l’optimiseur à se comporter différemment. On peut aussi l’aider on lui donnant quelques impératifs… Mais cette façon de faire n’est généralement pas la plus intelligente, car elle enferme l’optimiseur dans un carcan qui peut se révéler tôt ou tard plus handicapant qu’avantageux. Non, il existe d’autres moyens plus efficaces encore et ces autres moyens sont au nombre de deux : l’écriture de la requête et l’implantation judicieuse des index…

[2] SET STATISTICS IO ON pour la consommation des pages pour une requête et SET STATISTICS TIME ON pour la consommation CPU.
[3]Rappelons que la cardinalité n’est autre que le nombre de liens entre deux éléments : un à un, un à plusieurs, plusieurs à plusieurs.