Optimisation de requêtes : les réflexes de base

Optimisation de requêtes SQL : diagnostiquer avant de corriger

Une requête lente ne se répare pas au hasard. Avant de modifier le SQL ou d’ajouter un index, il faut repérer où le moteur dépense son temps : lecture de lignes, jointure, tri ou transfert de données.

Dans une boutique en ligne, par exemple, une page de commandes peut ralentir quand la table grandit, même si le code n’a pas changé. L’optimisation commence par mesurer ce qui se passe réellement, puis par choisir une correction adaptée.

EXPLAIN et profilage des requêtes lentes

Le premier réflexe consiste à examiner le plan d’exécution avec EXPLAIN, ou EXPLAIN ANALYZE lorsque le système le permet. Le premier décrit le plan envisagé ; le second fournit également des mesures observées lors de l’exécution.

Selon la documentation du système de gestion de base de données utilisé, les libellés et les détails du plan peuvent varier. Un parcours séquentiel n’est pas nécessairement mauvais sur une petite table ; sur un ensemble volumineux, il mérite toutefois une vérification.

Pour éviter de confondre perception et cause, l’équipe peut comparer une même requête avant et après modification, dans des conditions similaires. Elle examine aussi les statistiques et le volume effectivement renvoyé : parfois, le coût vient surtout d’un résultat trop large.

Signaux à vérifier :

• Parcours complet d’une table volumineuse
• Tri coûteux ou données temporaires sur disque
• Écart marqué entre lignes estimées et lignes traitées
• Durée élevée sur une jointure ou une agrégation

Un plan d’exécution n’est pas une recette automatique : il sert à formuler une hypothèse, que le profilage doit ensuite confirmer. Cette observation aide à distinguer un problème de requête d’un manque de ressources ou de statistiques à jour.

Limiter les colonnes et filtrer tôt

Une fois le point de ralentissement repéré, réduire le travail inutile est souvent la correction la plus simple. Remplacer SELECT * par une sélection explicite limite les données lues, transportées et parfois chargées en mémoire.

Pour une liste de commandes, l’application peut ne nécessiter que l’identifiant, la date et le montant, plutôt que chaque colonne descriptive. Ce choix rend aussi le besoin fonctionnel plus clair et peut permettre au moteur de répondre depuis un index couvrant, selon le plan obtenu.

Le filtrage mérite la même attention. Une condition comme YEAR(date_commande) = 2026 applique une fonction à la colonne ; selon le moteur et les index disponibles, cela peut empêcher une recherche efficace.

Une plage explicite est souvent préférable : date_commande >= '2026-01-01' AND date_commande < '2027-01-01'. Il faut néanmoins vérifier le type de la colonne, le fuseau horaire des données et le plan, plutôt que supposer un gain garanti.

Choix de requête :

• Colonnes nécessaires au résultat, sans sélection générale
• Filtres portant directement sur les valeurs stockées
• Bornes cohérentes avec le type des dates
• Résultats limités au besoin réel de l’application

Réduire les lignes en amont allège souvent les opérations suivantes, mais ne suffit pas toujours. Quand la requête relie plusieurs tables, l’ordre et le coût des jointures deviennent l’étape de diagnostic suivante.

Indexation et jointures : choisir des accès adaptés

Après la réduction des données, l’accès aux tables détermine souvent la suite du travail. Un index bien choisi peut éviter de parcourir des lignes sans rapport avec la requête, mais chaque index a un coût en stockage et en écriture.

Créer des index utiles sans les multiplier

Un index simple peut aider sur une recherche fréquente par identifiant, tandis qu’un index composé répond à des filtres portant sur plusieurs colonnes. L’ordre des colonnes compte : un index construit sur (client_id, date_commande) n’est pas équivalent à un index sur (date_commande, client_id).

Selon le moteur de base de données, les règles précises d’utilisation des index composés diffèrent. Dans de nombreux cas, l’index est particulièrement utile lorsque les conditions commencent par ses premières colonnes ; il faut le confirmer dans la documentation du système et dans le plan d’exécution.

Une équipe peut par exemple tester l’indexation de la clé client et de la date d’achat sur une table de commandes. Si les requêtes filtrent surtout par date, un ordre différent peut mieux correspondre à leur usage réel.

Décisions d’indexation :

• Index sur les colonnes fréquemment recherchées
• Ordre des colonnes conforme aux filtres courants
• Mesure du coût sur les opérations d’écriture
• Suppression des index redondants ou inutilisés

Un index n’accélère pas chaque requête : une colonne peu sélective ou une table minuscule peut rendre son usage inutile. Il faut mesurer les lectures et les écritures, puis conserver uniquement les structures qui répondent à un besoin observé.

Réduire le coût des jointures SQL

Une jointure relie des lignes de plusieurs tables à partir de colonnes communes. Pour la rendre efficace, on vérifie que les colonnes de liaison ont des types compatibles et que les filtres limitent le volume traité.

Dans un rapport de ventes, filtrer d’abord les commandes sur une période peut réduire les lignes à relier aux clients et aux détails des achats. L’optimiseur peut réorganiser les opérations ; réécrire une requête avec une expression commune ne garantit donc pas, à elle seule, un meilleur plan.

Selon les statistiques disponibles et les distributions de données, le moteur peut choisir une boucle imbriquée, une jointure par hachage ou une autre méthode. Le plan et les mesures permettent de voir si ce choix correspond au volume réel.

Comparaison des méthodes :

Opération observée	Rôle courant	Point de vigilance
Parcours séquentiel	Lecture complète d’une table	Coût potentiel sur un grand volume
Recherche par index	Accès ciblé aux lignes correspondantes	Utilité liée aux filtres et à la sélectivité
Jointure par hachage	Association de grands ensembles	Mémoire disponible et taille des données
Boucle imbriquée	Comparaison répétée entre ensembles	Peut coûter cher si les volumes augmentent

Quand les tables et les filtres sont maîtrisés, les lenteurs apparaissent parfois dans des usages différents : pages profondes, modifications massives ou calculs répétés. Ces cas demandent des stratégies spécifiques plutôt qu’un index supplémentaire.

Pagination et traitements : adapter les réflexes aux volumes

Les requêtes ponctuelles ne sont pas les seules à peser sur une base. La pagination, les mises à jour volumineuses et les agrégations répétées peuvent créer des ralentissements qui s’amplifient avec le nombre de lignes.

Choisir une pagination efficace

La pagination classique avec LIMIT et OFFSET est facile à comprendre et convient souvent aux petits résultats. Toutefois, pour atteindre une page très éloignée, le moteur peut devoir parcourir puis écarter de nombreuses lignes, selon le plan choisi.

La pagination par curseur, souvent appelée keyset, s’appuie sur la dernière valeur affichée. Dans une liste triée par date et identifiant, la page suivante demande les lignes situées après ce couple de valeurs, avec un ordre stable et des colonnes appropriées.

Cette méthode convient notamment aux fils d’actualité ou aux historiques parcourus progressivement. Elle offre moins de souplesse pour sauter directement à une page donnée ; le choix dépend donc de l’interface et du parcours attendu.

Repères de pagination :

• Petits résultats et accès direct aux pages : LIMIT et OFFSET
• Défilement continu : curseur fondé sur un tri stable
• Résultats reproductibles : ajout d’une clé unique au tri
• Performances comparées sur les volumes réellement utilisés

La pagination par curseur ne dispense pas de contrôler le plan ni de choisir un index pertinent. Elle évite surtout de demander au moteur de sauter un grand nombre de lignes avant de produire la page voulue.

Traiter les écritures lourdes et les calculs récurrents

Pour une suppression massive de journaux, découper le travail en lots peut limiter la durée de chaque opération et faciliter le suivi. La taille des lots doit être testée : un lot trop grand prolonge les verrous, un lot trop petit multiplie les opérations.

Les tableaux de bord posent un autre problème lorsqu’ils recalculent les mêmes agrégats à chaque consultation. Une vue matérialisée peut stocker le résultat, mais elle exige une stratégie de rafraîchissement et consomme de l’espace.

Une équipe peut aussi examiner la mise en cache pour les résultats qui changent peu, en tenant compte du délai acceptable avant actualisation. Le cache déplace une partie du coût ; il ne corrige pas une requête mal conçue et doit être invalidé de façon cohérente.

Solutions selon le besoin :

Situation	Approche possible	Contrôle nécessaire
Suppression volumineuse	Exécution par lots	Progression, verrous et taille des transactions
Agrégats souvent consultés	Vue matérialisée	Fréquence et coût du rafraîchissement
Résultats peu changeants	Mise en cache	Validité et durée de conservation
Table très volumineuse et filtrée par date	Étude du partitionnement	Clé de partition et requêtes sans filtre

Le partitionnement ne constitue pas un raccourci universel : il devient pertinent lorsque les requêtes et la maintenance profitent réellement de la séparation des données. Dans tous les cas, le réflexe durable reste le même : mesurer, modifier une chose à la fois et comparer le résultat.

La performance dépend autant du contexte que de la syntaxe : volume, statistiques, index et habitudes d’accès se combinent. Un diagnostic lisible évite les optimisations de façade et oriente chaque changement vers un problème concret.

À retenir

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