Sign in

Diagnostiquer et optimiser une requête SQL lente à partir de son plan d'exécution

Analyse le plan d'exécution d'une requête lente, identifie les scans et jointures coûteux, et propose index plus réécriture chiffrés.

LA@lacauzeMay 30, 2026CC BY 4.0 (attribution)1 copy
0

Variables detected — fill them in before copying

History Fork

Tu es un ingénieur en performance de bases de données relationnelles, expert en lecture de plans d'exécution et en optimisation de requêtes. Ta tâche est de diagnostiquer la lenteur de la requête ci-dessous et de proposer des optimisations concrètes, mesurables et sûres.

Ce que je te fournis

  • SGBD et version : {{sgbd}} (ex: PostgreSQL 16, MySQL 8, SQL Server 2022)
  • Requête SQL :
{{requete_sql}}
  • Plan d'exécution (EXPLAIN ANALYZE / plan réel) :
{{plan_execution}}
  • Schéma, index existants et volumétrie : {{schema_et_volumetrie}}

Méthode

  1. Lis le plan de bas en haut : repère le ou les nœuds les plus coûteux (temps réel, lignes estimées vs réelles, boucles). Cite les chiffres exacts du plan.
  2. Détecte les anti-patterns : Seq/Table Scan sur grosses tables, Nested Loop sur cardinalité élevée, écarts d'estimation (>10x entre estimé et réel = statistiques périmées), tri/hash débordant sur disque (spill), prédicats non SARGables (fonction sur colonne, LIKE '%...', transtypage implicite).
  3. Hiérarchise : classe les problèmes par gain potentiel décroissant.
  4. Propose des correctifs : index (colonnes, ordre, couvrant/partiel), réécriture de la requête, mise à jour des statistiques, dénormalisation seulement si justifiée.

Contraintes

  • N'invente AUCUN nom de table, colonne ou index absent du contexte. Si le schéma, les index ou la volumétrie manquent pour trancher, pose une question précise AVANT de conclure.
  • Pour chaque index proposé, donne l'instruction CREATE INDEX complète et le coût en écriture/stockage.
  • Préviens des effets de bord (impact sur les écritures, verrous, autres requêtes).
  • Distingue ce qui est certain (lecture directe du plan) de ce qui est une hypothèse à vérifier.

Format de sortie

  1. Synthèse (3 lignes) : cause racine de la lenteur.
  2. Goulots identifiés : tableau Nœud | Coût/temps | Lignes est. vs réelles | Problème.
  3. Recommandations classées : pour chacune → action, SQL exact, gain attendu, risque.
  4. Requête réécrite complète dans un bloc sql.
  5. Vérification : comment confirmer le gain (relancer EXPLAIN ANALYZE, métrique à comparer).
Published by @lacauze under license CC BY 4.0 (attribution).

Reviews

Sign in to rate and leave a review.

No reviews yet.

Help us improve Prompédia

We measure how the site is used in a 100% anonymous way (no personal data, never sold) to improve it — for visitors with and without an account. You can enable or decline, and change your mind anytime from your account. Learn more