Avant tout : un message d’erreur est un indice
Un message d’erreur SQL donne souvent 2 informations : le type de problème
(syntax, table inconnue, colonne inconnue…) et l’endroit où l’erreur a été détectée.
Apprendre à lire ça vous fait gagner énormément de temps.
Une erreur, c’est un GPS qui vous dit : “Tournez à gauche… ici”.
Si vous ignorez l’indication, vous vous perdez. Si vous la suivez, vous corrigez vite.
Ne changez pas 10 choses d’un coup. Faites une correction, retestez, puis continuez.
La méthode simple pour corriger (toujours la même)
La même méthode fonctionne pour la majorité des erreurs SQL, que vous soyez débutant ou confirmé.
1
Lire le message d’erreur
Identifiez ce que SQL n’aime pas : syntaxe, nom, type, contrainte…
2
Isoler la requête
Supprimez temporairement JOIN/WHERE/GROUP BY pour tester une version simple.
3
Vérifier les noms
Nom exact des tables/colonnes, alias, orthographe, pluriel/singulier.
4
Reconstruire étape par étape
SELECT → WHERE → JOIN → GROUP BY → HAVING → ORDER BY → LIMIT.
Les erreurs les plus courantes (et comment les corriger)
Les exemples ci-dessous sont volontairement simples pour que vous compreniez la logique.
Dans votre base, les noms peuvent être différents, mais le principe reste identique.
1) Erreur de syntaxe
Une erreur de syntaxe vient souvent d’un mot-clé mal écrit, d’une virgule oubliée,
ou d’une parenthèse qui manque.
SELECT * FORM films;
SELECT * FROM films;
Si l’erreur dit “near …”, regardez le mot indiqué : c’est souvent juste avant que ça coince.
2) Table inexistante (ou mauvais schéma)
Très courant quand on se trompe de nom (singulier/pluriel) ou qu’on n’est pas dans la bonne base.
SELECT * FROM film;
Vérifiez le nom exact de la table dans votre outil (phpMyAdmin, DBeaver, etc.).
Une lettre en moins suffit à casser la requête.
3) Colonne inexistante
Même principe : vous demandez une colonne qui n’existe pas, ou vous avez mal écrit son nom.
SELECT titre, notes FROM films;
Faites un SELECT * ponctuel pour voir les noms exacts des colonnes,
puis revenez à une sélection propre (liste de colonnes).
4) Colonne ambiguë (JOIN)
Quand vous joignez des tables, elles ont souvent des colonnes identiques (id, created_at…).
Si vous écrivez SELECT id, SQL ne sait pas lequel vous voulez.
SELECT id
FROM commandes JOIN clients ON commandes.client_id = clients.id;
SELECT commandes.id
FROM commandes JOIN clients ON commandes.client_id = clients.id;
Utilisez des alias : commandes co, clients c,
puis co.id, c.id, etc.
5) GROUP BY incorrect
Règle : si vous utilisez GROUP BY, toute colonne dans SELECT doit être
soit dans GROUP BY, soit agrégée (COUNT, AVG, SUM…).
SELECT titre, COUNT(*)
FROM films
GROUP BY annee;
Soit vous regroupez par titre, soit vous l’enlevez,
soit vous changez l’objectif (ex : stats par année).
6) WHERE vs HAVING (classique)
WHERE filtre les lignes avant GROUP BY.
HAVING filtre les groupes après GROUP BY.
Si vous utilisez COUNT dans votre condition, c’est presque toujours HAVING.
SELECT annee, COUNT(*)
FROM films
WHERE COUNT(*) > 1
GROUP BY annee;
SELECT annee, COUNT(*)
FROM films
GROUP BY annee
HAVING COUNT(*) > 1;
7) NULL : comparaison incorrecte
NULL signifie “valeur inconnue / absente”.
On ne compare pas NULL avec =. On utilise IS NULL / IS NOT NULL.
SELECT * FROM clients WHERE email = NULL;
SELECT * FROM clients WHERE email IS NULL;
NULL n’est ni une chaîne vide (''), ni zéro (0).
C’est une notion à part.
8) Erreurs de contraintes (PRIMARY KEY, UNIQUE, FOREIGN KEY)
Quand la base refuse un INSERT/UPDATE, c’est souvent à cause d’une contrainte.
La bonne nouvelle : la base protège vos données.
🪪
PRIMARY KEY
Un identifiant doit être unique. Deux lignes ne peuvent pas avoir le même id.
🔐
UNIQUE
Une valeur (ex : email) ne doit pas être dupliquée.
🔗
FOREIGN KEY
Une clé étrangère doit pointer vers un parent existant.
🧯
Solution
Vérifier les données (parent existant, pas de doublon) avant l’insertion.
INSERT INTO commandes (id, client_id) VALUES (1, 999);
Vérifiez d’abord que le parent existe :
SELECT id FROM clients WHERE id = 999;
Checklist rapide quand “ça ne marche pas”
🔎
1) Noms
Table/colonne/alias : exacts ? orthographe ? pluriel ?
🧱
2) Structure
Parenthèses, virgules, FROM, ORDER BY… tout est à sa place ?
🧩
3) JOIN
Condition ON correcte (FK = PK) ? colonnes ambiguës ?
📊
4) Agrégats
GROUP BY cohérent ? HAVING au bon endroit ?
Exercice pratique : diagnostiquer et corriger
Pour chaque requête, identifiez l’erreur probable puis écrivez une version corrigée.
L’objectif est de pratiquer la lecture “logique”.
1) Table inconnue
SELECT nom FROM client;
2) COUNT mal placé
SELECT COUNT(note) FROM films WHERE COUNT(note) > 5;
3) JOIN ambigu
SELECT id FROM films JOIN acteurs ON id = film_id;
Bonus
Transformez le 3) en version pro avec des alias (f, a) et une condition ON correcte.
- 1) Vérifier le bon nom de table (souvent
clients).
- 2) COUNT + filtre =
GROUP BY + HAVING (ou supprimer WHERE).
- 3) Préciser les colonnes :
films.id / acteurs.film_id et faire un ON valide.
Récapitulatif du chapitre
- Lire un message d’erreur SQL comme un indice
- Corriger les erreurs de syntaxe, tables/colonnes inconnues
- Éviter les pièges en JOIN (colonnes ambiguës)
- Comprendre les erreurs GROUP BY / WHERE / HAVING
- Gérer correctement NULL
- Identifier les erreurs liées aux contraintes (PK/UNIQUE/FK)
- Appliquer une méthode de débogage simple et efficace
Prochain chapitre : Bonnes pratiques SQL (lisibilité, sécurité, performance).