Accueil›Blog›Exercice SQL « débugger une requête lente »

Tests prêts à l'emploi

Exercice SQL « débugger une requête lente » : le test live qui révèle le vrai niveau

Rien ne révèle mieux le niveau SQL qu'un débogage en direct. On donne une requête lente et mal écrite, et on observe : le candidat tâtonne-t-il, ou diagnostique-t-il méthodiquement ? Voici l'exercice clé en main, avec les anti-patterns cachés et le corrigé.

Data Builder·Juillet 2025·10 min de lecture·Test SQL · live · débogage / performance

Sommaire

La requête à débugger
Les anti-patterns à repérer
Le corrigé
Grille par niveau

L'intérêt de cet exercice est la démarche, pas la réponse. Menez-le en live (partage d'écran) : vous verrez immédiatement qui lit un plan d'exécution et raisonne, et qui change des choses au hasard en espérant que ça aille plus vite.

1La requête à débugger

La consigne

Présentez cette requête au candidat : « elle est correcte mais très lente, améliore-la ».

Une requête réaliste qui « marche » mais accumule les anti-patterns de performance. Le candidat doit d'abord comprendre ce qu'elle fait, puis identifier pourquoi elle est lente.

-- Requete correcte mais lente : que corrigeriez-vous ?
SELECT *
FROM commandes o
JOIN clients c ON CAST(c.id AS CHAR) = CAST(o.client_id AS CHAR)  -- (1)
WHERE LOWER(c.pays) = 'france'                                    -- (2)
  AND o.date_commande > DATE_SUB(NOW(), INTERVAL 365 DAY)
  AND o.montant > (SELECT AVG(montant) FROM commandes)            -- (3)
ORDER BY o.date_commande DESC;

2Les anti-patterns à repérer

La consigne

Voici ce qu'un bon candidat identifie (numérotés dans la requête).

Trois problèmes principaux se cachent dans cette requête. Un candidat solide les repère et explique pourquoi chacun ralentit l'exécution.

(1) La jointure sur des colonnes converties (CAST) empêche l'usage des index.
(2) LOWER() sur la colonne filtrée empêche aussi l'index : mieux vaut normaliser en amont.
(3) La sous-requête d'AVG peut être recalculée ; et SELECT * ramène des colonnes inutiles.
Bon signe : le candidat veut voir le plan d'exécution (EXPLAIN) avant de conclure.

3Le corrigé

La consigne

Une version réécrite, plus rapide et lisible.

On ne cherche pas LA requête parfaite mais une version qui lève les blocages : jointure sur les bons types, filtre indexable, sous-requête sortie, colonnes explicites.

-- Version corrigee
SELECT o.id, o.date_commande, o.montant, c.nom
FROM commandes o
JOIN clients c ON c.id = o.client_id          -- meme type, index OK
WHERE c.pays = 'France'                         -- valeur normalisee, index OK
  AND o.date_commande >= DATE_SUB(NOW(), INTERVAL 365 DAY)
  AND o.montant > :avg_montant                  -- calcule une fois en amont
ORDER BY o.date_commande DESC;
-- + index sur commandes(date_commande) et clients(pays).

Jointure directe sur les identifiants (mêmes types, index utilisables).
Filtre sur une colonne pays normalisée, sans fonction.
Moyenne calculée une fois, colonnes explicitement listées.

Signal d'alerte : ce que ça révèle : un junior modifie des morceaux au hasard ; un senior lit le plan, formule une hypothèse, la teste et explique chaque changement. C'est cette démarche qu'il faut noter.

4Grille par niveau

Niveau	Maîtrise attendue	Signal GO	NO-GO
Junior	Repère SELECT * et un filtre évident	Améliore la lisibilité	Change des choses au hasard
Confirmé	Repère les fonctions bloquant l'index	Explique pourquoi c'est lent	Corrige sans comprendre la cause
Senior	Veut lire le plan d'exécution	Diagnostique avant d'optimiser	Optimise à l'aveugle
Lead	Priorise les corrections par impact	Chiffre le gain et explique clairement	Ne sait pas justifier ses changements

Home›Blog›SQL ‘debug a slow query’ exercise

Ready-to-use tests

SQL ‘debug a slow query’ exercise: the live test that reveals the real level

Nothing reveals SQL level better than live debugging. You give a slow, badly written query and observe: does the candidate fumble, or diagnose methodically? Here's the turnkey exercise, with the hidden anti-patterns and the answer.

Data Builder·July 2025·10 min read·SQL test · live · debugging / performance

Contents

The query to debug
The anti-patterns to spot
The answer
Level grid

The point of this exercise is the approach, not the answer. Run it live (screen share): you'll immediately see who reads an execution plan and reasons, and who changes things at random hoping it goes faster.

1The query to debug

The task

Show this query to the candidate: ‘it's correct but very slow, improve it’.

A realistic query that ‘works’ but stacks performance anti-patterns. The candidate must first understand what it does, then identify why it's slow.

-- Requete correcte mais lente : que corrigeriez-vous ?
SELECT *
FROM commandes o
JOIN clients c ON CAST(c.id AS CHAR) = CAST(o.client_id AS CHAR)  -- (1)
WHERE LOWER(c.pays) = 'france'                                    -- (2)
  AND o.date_commande > DATE_SUB(NOW(), INTERVAL 365 DAY)
  AND o.montant > (SELECT AVG(montant) FROM commandes)            -- (3)
ORDER BY o.date_commande DESC;

2The anti-patterns to spot

The task

Here's what a good candidate identifies (numbered in the query).

Three main problems hide in this query. A strong candidate spots them and explains why each slows execution.

(1) Joining on converted columns (CAST) prevents index usage.
(2) LOWER() on the filtered column also prevents the index: better to normalize upstream.
(3) The AVG subquery may be recomputed; and SELECT * pulls useless columns.
Good sign: the candidate wants to see the execution plan (EXPLAIN) before concluding.

3The answer

The task

A rewritten version, faster and more readable.

We don't look for THE perfect query but a version that removes the blockers: join on the right types, indexable filter, extracted subquery, explicit columns.

-- Version corrigee
SELECT o.id, o.date_commande, o.montant, c.nom
FROM commandes o
JOIN clients c ON c.id = o.client_id          -- meme type, index OK
WHERE c.pays = 'France'                         -- valeur normalisee, index OK
  AND o.date_commande >= DATE_SUB(NOW(), INTERVAL 365 DAY)
  AND o.montant > :avg_montant                  -- calcule une fois en amont
ORDER BY o.date_commande DESC;
-- + index sur commandes(date_commande) et clients(pays).

Direct join on the identifiers (same types, usable indexes).
Filter on a normalized country column, without a function.
Average computed once, columns explicitly listed.

Warning signal : what it reveals: a junior changes bits at random; a senior reads the plan, forms a hypothesis, tests it and explains each change. It's that approach you should score.

4Level grid

Level	Expected proficiency	Signal GO	NO-GO
Junior	Spots SELECT * and one obvious filter	Improves readability	Changes things at random
Mid-level	Spots functions blocking the index	Explains why it's slow	Fixes without understanding the cause
Senior	Wants to read the execution plan	Diagnoses before optimizing	Optimizes blindly
Lead	Prioritizes fixes by impact	Quantifies the gain and explains clearly	Can't justify their changes

Exercice SQL « débugger une requête lente » : le test live qui révèle le vrai niveau

1La requête à débugger

2Les anti-patterns à repérer

3Le corrigé

4Grille par niveau

SQL ‘debug a slow query’ exercise: the live test that reveals the real level

1The query to debug

2The anti-patterns to spot

3The answer

4Level grid

Vous recrutez un profil data ?