Une page qui ralentit ne réclame pas forcément un serveur plus puissant. Dans bien des cas, quelques requêtes mal choisies augmentent le temps de réponse et masquent la véritable cause.
Un diagnostic efficace commence par des mesures, puis suit le plan d’exécution jusqu’au point de blocage. Cette démarche aide à distinguer une requête lente d’un problème de connexions, de concurrence ou d’allers-retours répétés.
À retenir :
- Mesure des requêtes coûteuses avant toute modification technique
- Lecture du plan d’exécution et des lignes réellement traitées
- Vérification des index, des statistiques et des appels répétés
- Nouvelle mesure après chaque correction ciblée
Repérer une requête lente grâce aux bonnes mesures
Après avoir défini le symptôme, l’analyse des performances doit commencer au niveau de l’application et de la base. Une page qui paraît lente ne désigne pas forcément une requête lente : le navigateur, le réseau ou l’attente d’une connexion peuvent aussi peser.
Classer les requêtes selon leur coût réel
Pour établir les priorités, regardez le temps cumulé plutôt que le seul pire temps observé. Une opération de deux secondes lancée rarement peut peser moins qu’une instruction de quelques dizaines de millisecondes répétée des milliers de fois.
Selon la documentation de PostgreSQL, l’extension pg_stat_statements regroupe des statistiques par instruction normalisée, notamment le nombre d’appels et le temps d’exécution. MySQL propose des informations comparables dans son schéma Performance Schema, utiles pour orienter le profilage.
Le journal des requêtes lentes complète ces données, mais son seuil peut cacher des opérations courtes et très fréquentes. Il faut également vérifier si la lenteur apparaît à chaque appel ou seulement pendant les périodes de forte activité.
Les signaux à comparer :
- Temps cumulé et nombre d’appels par instruction
- Durée moyenne et variations selon l’heure
- Volume de requêtes par page ou requête HTTP
- Charge de la base de données et attente de connexions
Ce premier tri évite de confondre une instruction coûteuse avec une file d’attente ou un excès d’appels. Une fois les principales candidates identifiées, l’étape suivante consiste à examiner leur exécution réelle.
Relier le symptôme à la couche responsable
Le temps de réponse se décompose entre navigateur, réseau, application et base de données. Les outils de développement du navigateur éclairent le chargement des ressources, tandis que les traces serveur révèlent le temps passé avant la réponse.
Par exemple, une page qui reste lente alors que la base est peu sollicitée peut attendre un pool de connexions saturé. À l’inverse, une hausse simultanée des durées SQL et de l’activité de la base justifie une inspection des instructions concernées.
| Observation | Cause à vérifier | Mesure utile |
|---|---|---|
| Temps SQL élevé à chaque appel | Plan ou indexation | Comparer estimations et durées réelles |
| Latence élevée, base peu chargée | Pool de connexions | Examiner attente et connexions actives |
| Nombre d’appels lié aux éléments affichés | Requêtes N+1 | Compter les appels par page |
| Retards concentrés sur certaines périodes | Verrous ou concurrence | Observer les attentes et transactions |
Lire le plan d’exécution avant l’optimisation SQL
Quand les mesures désignent une instruction, le plan d’exécution montre comment la base compte la traiter. Selon la documentation de PostgreSQL, EXPLAIN présente ce plan, tandis qu’EXPLAIN ANALYZE exécute la requête et rapporte des mesures effectives.
Identifier le nœud qui consomme le temps
Un balayage séquentiel n’est pas automatiquement une erreur : sur une petite table, ou pour récupérer une grande partie des lignes, il peut être plus efficace qu’un parcours d’index. Sur une grande table filtrée, il mérite toutefois une vérification attentive.
Comparez aussi les lignes estimées aux lignes réellement traitées. Un écart marqué peut indiquer des statistiques périmées, notamment après un chargement important ou une suppression massive, et pousser le planificateur vers une stratégie inadaptée.
Dans PostgreSQL, EXPLAIN ANALYZE lance effectivement l’instruction. Selon la documentation du moteur, il faut donc prendre des précautions avant de l’utiliser sur une commande qui modifie des données, en particulier en production.
Les indices à examiner dans le plan :
- Balayage séquentiel sur une table volumineuse
- Écart important entre lignes prévues et observées
- Nœud concentrant la majeure partie du temps
- Conditions de filtrage et colonnes de jointure
Corriger le nœud lent cible le problème au lieu d’optimiser une partie sans effet. L’indexation peut alors aider, à condition que la requête et la structure de l’index soient compatibles.
Choisir des index adaptés aux filtres
Un index existant peut rester inutilisé si la condition transforme la colonne par une fonction ou un calcul. Réécrire le filtre pour comparer directement la colonne peut permettre au moteur de s’appuyer sur l’index disponible.
Les index composites dépendent également de l’ordre de leurs colonnes : un index commençant par une colonne ne répond pas toujours à une recherche portant uniquement sur une autre. Selon la documentation MySQL, le choix et l’usage des index doivent être évalués avec les requêtes concernées.
Chaque index supplémentaire impose aussi du travail lors des écritures et occupe de l’espace. Avant d’en créer un, vérifiez la fréquence des filtres, le nombre de lignes renvoyées et la fraîcheur des statistiques.
| Constat | Vérification | Action envisageable |
|---|---|---|
| Colonne enveloppée dans une fonction | Forme de la condition | Réécrire le filtre si possible |
| Index composite peu utile | Ordre des colonnes | Adapter l’index aux filtres réels |
| Beaucoup de lignes retournées | Part de table lue | Réduire le résultat demandé |
| Estimations peu fiables | Fraîcheur des statistiques | Actualiser les statistiques |
Corriger les problèmes d’appels, de verrous et de connexions
Un plan correct ne garantit pas une page rapide, car le coût peut venir de nombreux allers-retours ou d’attentes autour de la base. Avant de renforcer le matériel, vérifiez ces mécanismes souvent confondus avec un défaut SQL.
Détecter les requêtes N+1 et réduire les allers-retours
Le schéma N+1 apparaît lorsqu’une application charge une liste, puis lance une requête distincte pour chaque élément associé. Cent enregistrements peuvent ainsi provoquer cent appels supplémentaires, même si chaque requête est individuellement rapide.
Un comptage des appels par requête HTTP révèle le problème : si leur nombre augmente avec les éléments affichés, le chargement des données liées mérite une révision. Un ORM peut souvent récupérer ces données en groupe, au lieu de les demander une à une.
Pour limiter ce type de surcoût :
- Compter les requêtes déclenchées par chaque page
- Charger les relations en une opération groupée
- Paginer les listes trop volumineuses
- Ne sélectionner que les champs nécessaires
Cette vérification est particulièrement utile lorsque la distance réseau augmente le coût de chaque aller-retour. Si les appels restent peu nombreux, les verrous et les connexions deviennent les pistes suivantes.
Écarter la contention et l’épuisement des connexions
Une transaction qui garde un verrou pendant un travail externe peut bloquer les opérations suivantes. Garder les transactions courtes et limiter leur contenu aux opérations de base de données réduit ce risque.
Un pool mal dimensionné produit un autre tableau : les demandes attendent une connexion, alors que le processeur de la base peut rester peu sollicité. Le pooling et l’observation des files d’attente sont alors plus pertinents qu’une machine plus puissante.
Après chaque changement, répétez la mesure sur le même parcours et dans des conditions comparables. Une optimisation SQL n’est confirmée que si le temps de réponse s’améliore sans dégrader les écritures ou les autres usages.
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
