SQL WHERE : filtrer des lignes avec AND, OR et NULL

La clause SQL WHERE filtre les lignes d’une table selon une condition. Dans une requête SQL, la clause WHERE ne conserve une ligne que si le prédicat s’évalue à TRUE ; les résultats FALSE et NULL/UNKNOWN sont exclus. Cette logique à trois valeurs est la source la plus fréquente des comportements inattendus de WHERE autour des valeurs NULL.

Exemple de clause SQL WHERE pour filtrer des lignes

Sortie :

+---------+--------------+-------+
| nom     | categorie    | prix  |
+---------+--------------+-------+
| Clavier | Electronique | 49.99 |
| Souris  | Electronique | 25.0  |
+---------+--------------+-------+
2 row(s)

Comment cet exemple fonctionne

1. CREATE TABLE et INSERT construisent une table produits avec quatre lignes réparties sur deux catégories.
2. La clause WHERE categorie = 'Electronique' AND prix < 100 combine deux conditions avec AND ; les deux doivent être TRUE pour qu’une ligne apparaisse.
3. “Moniteur” est dans la catégorie Electronique mais coûte 299.00, donc la condition sur le prix l’élimine. “Cahier” échoue au filtre de catégorie. Seuls “Clavier” et “Souris” satisfont les deux prédicats.

Qu’est-ce qu’une clause SQL WHERE ?

Une clause SQL WHERE est un filtre booléen appliqué à chaque ligne individuellement. La base de données évalue l’expression pour chaque ligne candidate et ne garde que celles où le résultat est TRUE. Toute expression qui renvoie FALSE ou NULL est supprimée. WHERE s’exécute avant GROUP BY et les fonctions d’agrégation, ce qui la distingue de HAVING.

Erreurs courantes avec les clauses SQL WHERE

Erreur : comparer une colonne à NULL avec =.

Faux :

WHERE categorie = NULL

Correct :

WHERE categorie IS NULL

Pourquoi : = NULL s’évalue à UNKNOWN, et WHERE filtre les lignes UNKNOWN. Utilisez IS NULL ou IS NOT NULL.

Erreur : mélanger AND et OR sans parenthèses.

Faux :

WHERE categorie = 'Bureau' OR categorie = 'Electronique' AND prix < 50

Correct :

WHERE (categorie = 'Bureau' OR categorie = 'Electronique') AND prix < 50

Pourquoi : AND a une priorité plus forte que OR, donc les parenthèses sont nécessaires pour respecter votre intention.

WHERE vs HAVING

Règle : utilisez WHERE pour exclure des lignes avant l’agrégation, et HAVING pour exclure des groupes après. Filtrer tôt avec WHERE réduit le travail de l’étape d’agrégation.

Considérations de performance

Des prédicats WHERE sur des colonnes indexées transforment un scan complet de table en recherche par index. Envelopper la colonne dans une fonction, comme LOWER(nom) ou DATE(created_at), empêche l’optimiseur d’utiliser l’index ; transformez plutôt la valeur comparée. Pour des conditions reliées par AND, un index composite qui suit l’ordre des colonnes du prédicat offre les meilleures performances. Les conditions OR produisent souvent des scans d’index séparés ensuite fusionnés, ce qui est plus lent qu’un AND sur le même index.

Notes de sécurité

Construisez les conditions WHERE avec des requêtes paramétrées, jamais en concaténant l’entrée utilisateur dans des chaînes SQL. Pour les noms de colonnes dynamiques, validez contre une allow-list stricte. Pour les listes IN (...), générez des placeholders et liez chaque valeur. Prévisualisez toujours les requêtes UPDATE et DELETE avec un SELECT qui utilise la même clause WHERE avant d’exécuter l’écriture.

FAQ

Quelle est la différence entre WHERE et HAVING en SQL ?

WHERE filtre les lignes avant GROUP BY ; HAVING filtre les groupes agrégés après. WHERE ne peut pas référencer des fonctions d’agrégation comme COUNT() ou SUM(). Une requête peut utiliser les deux : WHERE réduit les lignes d’entrée, puis HAVING réduit la sortie groupée.

Pourquoi = NULL ne fonctionne pas dans une clause WHERE ?

SQL utilise une logique à trois valeurs : TRUE, FALSE et UNKNOWN. Toute comparaison avec NULL renvoie UNKNOWN, et WHERE supprime les lignes UNKNOWN. Utilisez IS NULL pour tester les valeurs NULL. Certaines bases prennent aussi en charge IS NOT DISTINCT FROM pour des comparaisons d’égalité sûres avec NULL.

L’ordre des conditions WHERE affecte-t-il les performances ?

Le standard SQL ne garantit pas l’ordre d’évaluation, et la plupart des optimiseurs réordonnent les prédicats en interne. Écrivez les conditions dans l’ordre le plus lisible. Les performances dépendent des colonnes indexées et de la sélectivité de chaque prédicat, pas de l’ordre d’écriture.