Leçon 14 / 20

Lire un plan d’exécution SQL

20 min PHP 8 — architecture, tests et sécurité Gratuit

Objectif : Lire le plan d’une requête de recherche et repérer si la base examine inutilement de nombreuses lignes.

Une recherche peut sembler simple tout en obligeant la base à examiner un grand nombre de contacts. Le résultat arrive alors plus lentement à mesure que le carnet grandit. Pour comprendre ce travail, vous pouvez demander au moteur SQL de décrire comment il prévoit d’exécuter la requête.

Dans cette leçon, vous utilisez EXPLAIN sur une recherche par nom ou par courriel, puis vous repérez les signes d’un parcours de table coûteux. Le plan est un outil de diagnostic : il vous aide à formuler une hypothèse, que vous devrez ensuite confronter à des mesures sur vos données.

Demander le plan au moteur SQL

EXPLAIN précède une requête et demande au moteur de présenter la stratégie choisie, sans exécuter la recherche pour renvoyer ses contacts comme résultat. Les colonnes affichées dépendent du moteur et de sa version ; les exemples ci-dessous correspondent à la forme tabulaire courante de MySQL. La leçon précédente vous a appris à établir une référence de durée ; ici, vous examinez plutôt le travail que la base prévoit d’effectuer.

SQL
EXPLAIN
SELECT id, nom, courriel, telephone
FROM contacts
WHERE nom LIKE '%martin%'
   OR courriel LIKE '%martin%'
ORDER BY nom;

Pour lancer ce diagnostic, exécutez cette instruction dans le client SQL de votre base, sur le même schéma et avec une requête représentative de la recherche du carnet. La liste des colonnes reprend les champs du formulaire et de la liste du projet. Si votre schéma emploie des noms différents, adaptez uniquement ces identifiants à la définition réelle de la table.

Repérer un parcours de table

Dans le résultat MySQL, commencez par la colonne type. Une valeur ALL indique un parcours de table : le moteur examine les lignes de la table pour trouver celles qui satisfont la condition. Regardez ensuite rows, qui donne une estimation du nombre de lignes à examiner, et filtered, estimation de la part qui passe le filtre. Ce sont des estimations du plan, pas le décompte garanti du travail réellement effectué.

Élément du planCe que vous examinez
type = ALLLe moteur prévoit un parcours de table.
rowsOrdre de grandeur des lignes estimées à examiner.
filteredPart estimée des lignes qui satisfait la condition.
ExtraInformations complémentaires, par exemple un tri ou un filtre.

Si le carnet contient quelques dizaines de lignes, examiner toute la table peut être parfaitement acceptable. Si l’estimation porte sur des centaines de milliers de lignes alors que la recherche ne renvoie que quelques contacts, le plan révèle un travail potentiellement disproportionné. C’est ce rapport entre les lignes examinées et les lignes utiles qui rend le parcours préoccupant, pas la seule présence de ALL.

Comprendre la sélectivité du filtre

La sélectivité décrit à quel point une condition réduit le nombre de lignes candidates. Une recherche qui ne correspond qu’à deux contacts parmi cent mille est très sélective ; une condition qui correspond à la moitié de la table l’est peu. Une estimation filtered faible indique que peu de lignes examinées passent le filtre : associée à une grande valeur de rows, elle peut signaler que la base fait beaucoup de travail pour produire peu de résultats.

La requête d’exemple cherche une sous-chaîne, car le motif commence par le caractère générique %. Le plan peut donc montrer un parcours de table, même si la recherche ne renvoie que peu de contacts. À ce stade, ne déduisez pas encore quelle correction appliquer : la leçon consacrée au choix d’un index étudiera les possibilités et leurs compromis. Ici, votre objectif est de constater et de décrire le coût apparent du plan.

Formuler un diagnostic exploitable

Notez la requête exacte, le volume de données, les conditions testées et les éléments du plan, notamment type, rows et filtered. Répétez l’observation pour un terme fréquent et un terme rare : la sélectivité varie selon les valeurs, et un plan observé pour un seul terme ne décrit pas nécessairement tous les cas. Gardez aussi la durée mesurée, car un parcours de table n’implique pas automatiquement une lenteur perceptible sur une petite table.

  • Utilisez EXPLAIN sur la requête réelle de recherche pour examiner la stratégie prévue par le moteur.
  • Dans MySQL, type = ALL signale un parcours de table ; lisez-le avec l’estimation rows et le contexte du volume de données.
  • La sélectivité indique dans quelle mesure le filtre réduit les lignes candidates.
  • Un plan fournit des estimations : confrontez-le à des mesures et à un jeu de données représentatif avant de choisir une correction.

Dans la prochaine leçon, vous étudierez comment choisir un index adapté à une colonne filtrée et comment évaluer le compromis associé aux écritures.

Envie d'aller plus loin ?

Les cours Enovatic sont gratuits et le resteront. Si vous cherchez un accompagnement encadré, nos formations professionnelles sont animées par les mêmes formateurs.