Un plan d’exécution montre comment une base de données prévoit de répondre à une requête SQL : quelles données lire, quels index utiliser et comment effectuer les jointures. Lorsqu’une application ralentit, cette représentation aide à repérer un goulot d’étranglement plutôt qu’à modifier le code au hasard.
Pour l’interpréter, comparez les opérations annoncées aux volumes de données et au résultat attendu. Une analyse de requête utile relie les choix du moteur à la performance observée, puis oriente une optimisation SQL vérifiable.
À retenir :
- Lecture des opérations et de leur ordre dans le plan d’exécution
- Comparaison des lignes estimées avec les lignes réellement parcourues
- Repérage des scans coûteux, des jointures et des index manquants
- Validation des améliorations par des mesures répétées et comparables
Lire un plan d’exécution SQL sans confondre coût et durée
Un plan décrit les étapes que le moteur choisit pour produire un résultat, et non une chronologie garantie en secondes. Selon la documentation PostgreSQL, la commande EXPLAIN affiche notamment les opérations prévues et leurs coûts estimés.
Repérer les opérations qui composent le plan
Les nœuds représentent des tâches telles que lire une table, parcourir un index ou combiner deux ensembles de lignes. Pour une requête clients-commandes, le plan peut d’abord filtrer les clients, puis joindre les commandes correspondantes.
Le coût d’exécution affiché est une estimation interne, pas une facture de temps directement comparable entre serveurs. Il sert surtout à confronter deux stratégies dans le même contexte et à chercher les opérations qui dominent le travail.
Un plan d’exécution se lit généralement des opérations les plus profondes vers les nœuds parents, qui agrègent ou transforment leurs résultats. La présentation diffère selon le système de gestion de base de données, mais les principes restent comparables.
Opérations fréquentes à reconnaître :
- Scan de table pour parcourir les lignes d’une relation
- Scan d’index pour exploiter un chemin d’accès indexé
- Jointure pour associer des lignes selon une condition
- Tri ou agrégation pour ordonner ou regrouper les résultats
Ces opérations prennent tout leur sens lorsqu’on les relie à la taille des tables et aux filtres utilisés ; c’est alors que le diagnostic devient concret.
Interpréter les estimations et les lignes observées
Pour vérifier une lenteur, confrontez le nombre de lignes estimées par le moteur au nombre réellement traité. Selon la documentation de MySQL, EXPLAIN présente les choix de planification ; les options disponibles pour observer l’exécution varient selon les versions.
Un écart important peut signaler des statistiques anciennes, une distribution de valeurs atypique ou un filtre peu sélectif. Si le moteur prévoit quelques dizaines de lignes mais en parcourt des milliers, il peut choisir une stratégie mal adaptée.
| Élément observé | Question à poser | Interprétation possible |
|---|---|---|
| Lignes estimées | Le volume prévu paraît-il plausible ? | Statistiques à contrôler |
| Lignes réelles | Combien de lignes sont effectivement traitées ? | Volume de travail constaté |
| Accès aux données | Le plan parcourt-il une table entière ? | Filtre ou index à examiner |
| Durée mesurée | Le temps inclut-il l’exécution complète ? | Mesure à comparer prudemment |
Les estimations orientent l’enquête, mais elles ne suffisent pas à expliquer seules une requête lente ; l’analyse doit ensuite se concentrer sur l’accès aux données.
Repérer un scan de table et un goulot d’étranglement
Quand les opérations sont identifiées, le volume parcouru permet de distinguer un choix raisonnable d’un véritable goulot d’étranglement. Selon la documentation Microsoft SQL Server, les plans d’exécution aident à comprendre comment le moteur accède aux données et traite une requête.
Évaluer l’intérêt réel d’un index
Un scan de table n’est pas automatiquement mauvais : il peut être efficace lorsque la table est petite ou que la requête demande une grande partie de ses lignes. En revanche, parcourir une table volumineuse pour ne conserver que quelques résultats mérite une vérification.
Un index peut accélérer la recherche sur les colonnes filtrées ou utilisées dans une jointure, mais il entraîne aussi un coût de stockage et de mise à jour. Pour une boutique fictive, indexer l’identifiant client des commandes peut aider une recherche ciblée ; l’effet doit être mesuré sur les requêtes réellement exécutées.
Signaux à examiner avant de créer un index :
- Filtre sélectif associé à un parcours très large
- Colonne de jointure sans accès efficace dans le plan
- Index existant dont l’ordre des colonnes ne correspond pas aux filtres
- Coût d’écriture accru après l’ajout de plusieurs index
Un index ne garantit donc pas une meilleure performance ; le choix dépend des données, des requêtes et des opérations concurrentes. L’étape suivante consiste à tester les changements sans attribuer tout progrès à une seule modification.
Comparer les jointures et les pistes de correction
Une jointure peut utiliser différentes méthodes selon le volume estimé, les index disponibles et les caractéristiques des données. Une boucle répétée sur un grand ensemble peut devenir coûteuse, tandis qu’une autre méthode convient mieux à des volumes importants.
Le tableau aide à relier un symptôme à une vérification, sans prescrire la même correction pour chaque moteur. Une réécriture SQL, un index ou une mise à jour des statistiques doivent être évalués avec des mesures comparables.
| Symptôme du plan | Vérification utile | Piste à tester |
|---|---|---|
| Scan large avec filtre restrictif | Index et sélectivité du prédicat | Tester un index adapté |
| Jointure sur beaucoup de lignes | Clés, filtres et cardinalités estimées | Réduire les lignes en amont |
| Tri volumineux | Ordre demandé et mémoire disponible | Examiner l’indexation et le tri |
| Résultat lent malgré peu de lignes | Attentes, réseau et charge concurrente | Mesurer l’ensemble du parcours |
Pour tester une optimisation SQL, conservez la requête initiale, mesurez-la dans des conditions proches, puis ne changez qu’un facteur à la fois. Cette méthode réduit les conclusions hâtives lorsque la charge du serveur varie.
Une lecture fiable combine enfin le plan, les volumes observés et le contexte de charge ; le diagnostic gagne ainsi en précision sans transformer chaque scan en problème.
- Mesures répétées avant et après chaque modification
- Vérification des effets sur les écritures et les autres requêtes
- Comparaison dans le même moteur et un contexte similaire
- Conservation du plan initial pour contrôler les changements
Un mot qui se comprend dossier après dossier
Qu'il s'agisse de philosophie bouddhiste, de méditation, de culture tibétaine, d'industrie durable, de linguistique ou de bien-être, chaque rubrique raconte une facette différente de la même question : comment un même mot peut porter, à la fois, une pensée millénaire et un usage bien actuel. Rien n'est figé : chaque contexte nouveau peut encore faire évoluer ce sens.
Pour aller plus loin
- Comparer plusieurs sources avant de juger la portée d'une traduction ou d'une définition
- Replacer chaque terme dans son contexte culturel réel, pas seulement sa traduction littérale
- S'intéresser aux usages vivants de la langue autant qu'aux définitions figées
- Observer comment un même mot évolue d'un domaine à l'autre au fil du temps
