La requête SELECT : WHERE, LIKE, ORDER BY

La requête SELECT lit les données d'une table : elle choisit les colonnes à afficher, garde les lignes qui vérifient la condition du WHERE et trie le résultat avec ORDER BY. Ce chapitre couvre aussi LIKE, IN, BETWEEN, le traitement de NULL, LIMIT et l'ordre dans lequel le SGBD évalue une requête. Les exemples interrogent la base d'exemple parc, dans son état initial.

Projection, expressions et alias

SELECT choisit les colonnes, FROM la table. L'étoile prend toutes les colonnes, dans l'ordre de la table :

SELECT * FROM service;

Dans une requête que tu gardes (une application, une vue, une copie d'examen), nomme les colonnes : le résultat ne change pas quand quelqu'un ajoute une colonne à la table, et le lecteur sait ce que tu affiches. Le choix des colonnes s'appelle la projection.

Une colonne du résultat peut être une expression calculée. Le mot-clé AS lui donne un alias, le nom qui apparaît dans l'en-tête :

SELECT num_inventaire, marque, modele, prix_achat,
       ROUND(prix_achat * 1.2, 2) AS prix_ttc
FROM poste
WHERE type_poste = 'portable'
ORDER BY prix_achat DESC, num_inventaire;

Le AS est facultatif (ROUND(...) prix_ttc), mais il rend la requête plus lisible. Choisis des alias sans espace ni accent : prix_ttc plutôt que prix TTC, qui t'obligerait à écrire des backquotes partout.

DISTINCT

DISTINCT supprime les lignes en double du résultat :

SELECT DISTINCT marque FROM poste ORDER BY marque;

DISTINCT porte sur la ligne entière, pas sur la première colonne. SELECT DISTINCT marque, type_poste renvoie chaque combinaison différente : Dell fixe, Dell portable, HP fixe, HP portable, Lenovo portable.

WHERE et les opérateurs logiques

WHERE garde les lignes pour lesquelles la condition est vraie. Les comparaisons s'écrivent =, <> (ou !=), <, <=, >, >=. Les conditions se combinent avec AND, OR et NOT.

L'ordre d'évaluation est NOT, puis AND, puis OR, comme la multiplication passe avant l'addition. Tu veux les tickets ouverts ou en cours, de priorité critique :

SELECT id_ticket, statut, priorite
FROM ticket
WHERE statut = 'ouvert' OR statut = 'en_cours' AND priorite = 'critique'
ORDER BY id_ticket;

Le AND est évalué d'abord : MySQL a compris ouvert OR (en_cours AND critique). Les tickets 7, 12 et 14 ne sont pas critiques. Avec des parenthèses :

SELECT id_ticket, statut, priorite
FROM ticket
WHERE (statut = 'ouvert' OR statut = 'en_cours') AND priorite = 'critique';

BETWEEN, IN, LIKE et REGEXP

BETWEEN teste un intervalle, bornes comprises : prix_achat BETWEEN 600 AND 1100 équivaut à prix_achat >= 600 AND prix_achat <= 1100.

IN teste l'appartenance à une liste : priorite IN ('haute', 'critique') équivaut à deux = reliés par OR.

LIKE compare à un motif. % remplace n'importe quelle suite de caractères (y compris aucune), _ remplace exactement un caractère.

SELECT id_ticket, titre FROM ticket WHERE titre LIKE '%Odoo%';

num_inventaire LIKE 'PC-001_' trouve les postes PC-0010 à PC-0015. Pour chercher un vrai % ou un vrai _, échappe-le : LIKE '%\_%'. Avec l'interclassement par défaut, LIKE ignore la casse et les accents, comme =.

REGEXP (ou REGEXP_LIKE()) compare à une expression régulière, avec la bibliothèque ICU depuis MySQL 8.0.4 :

SELECT num_inventaire, modele
FROM poste
WHERE modele REGEXP '^(OptiPlex|ProDesk)'
ORDER BY num_inventaire;

Elle renvoie les 7 postes fixes, dont les modèles commencent par OptiPlex ou ProDesk.

NULL et la logique à trois valeurs

NULL signifie « inconnu » ou « absent ». Ce n'est pas une valeur : toute comparaison avec NULL donne NULL, que SQL traite comme une troisième valeur de vérité, UNKNOWN (inconnu). WHERE ne garde que les lignes dont la condition vaut TRUE.

SELECT nom, prenom FROM employe WHERE telephone = NULL;    -- aucune ligne, jamais
SELECT nom, prenom FROM employe WHERE telephone IS NULL;   -- la bonne écriture

Les tables de vérité avec UNKNOWN :

Conséquence moins visible : une condition négative ignore aussi les NULL.

SELECT libelle, etage FROM service WHERE etage <> 2;

Juridique n'apparaît pas : NULL <> 2 vaut UNKNOWN. Si tu veux aussi les services sans étage, écris WHERE etage <> 2 OR etage IS NULL.

Toute opération avec NULL donne NULL : prix_achat + NULL vaut NULL, CONCAT('a', NULL) aussi. MySQL propose l'opérateur <=>, une égalité qui considère deux NULL comme égaux ; la norme et PostgreSQL écrivent IS NOT DISTINCT FROM.

ORDER BY

ORDER BY trie le résultat : ASC (croissant, par défaut) ou DESC. Plusieurs critères se départagent dans l'ordre où tu les écris. Tu peux trier sur une colonne, un alias du SELECT ou une expression.

SELECT libelle, etage FROM service ORDER BY etage, libelle;

MySQL place les NULL en premier dans un tri croissant et en dernier dans un tri décroissant. PostgreSQL fait l'inverse et propose NULLS FIRST ou NULLS LAST, que MySQL ne connaît pas. Pour envoyer les NULL à la fin avec MySQL, trie d'abord sur etage IS NULL, qui vaut 0 ou 1 : ORDER BY etage IS NULL, etage.

Sans ORDER BY, l'ordre des lignes n'est pas garanti. Il dépend du plan d'exécution et peut changer d'une version à l'autre.

LIMIT, OFFSET et pagination

LIMIT n garde les n premières lignes du résultat trié. Les trois postes les plus chers :

SELECT num_inventaire, prix_achat
FROM poste
ORDER BY prix_achat DESC, num_inventaire
LIMIT 3;

Le second critère de tri (num_inventaire) départage les deux postes à 1 249 €. Sans lui, MySQL pourrait renvoyer PC-0014 avant PC-0012, et un autre jour l'inverse.

OFFSET saute des lignes. Pour afficher une liste page par page, avec t lignes par page, la page p s'obtient avec LIMIT t OFFSET (p - 1) * t :

-- Page 2 des tickets, du plus récent au plus ancien, 5 par page
SELECT id_ticket, titre, date_ouverture
FROM ticket
ORDER BY date_ouverture DESC
LIMIT 5 OFFSET 5;

MySQL accepte aussi LIMIT 5, 5 (décalage, puis nombre) : l'ordre des deux nombres y est inversé, source d'erreurs. La norme SQL écrit OFFSET 5 ROWS FETCH FIRST 5 ROWS ONLY, forme que PostgreSQL et SQL Server comprennent ; SQL Server a aussi SELECT TOP (5).

Ordre d'écriture, ordre d'exécution

Tu écris une requête dans un ordre imposé par la syntaxe. Le SGBD l'évalue, logiquement, dans un autre ordre :

Cet ordre explique des erreurs qui semblent arbitraires :

SELECT num_inventaire, ROUND(prix_achat * 1.2, 2) AS prix_ttc
FROM poste
WHERE prix_ttc > 1300;

ERROR 1054 (42S22): Unknown column 'prix_ttc' in 'where clause'

Quand WHERE s'exécute, SELECT n'a pas encore calculé prix_ttc. Répète l'expression dans le WHERE (WHERE prix_achat * 1.2 > 1300) ou passe par une sous-requête. En revanche, ORDER BY prix_ttc fonctionne : le tri vient après le SELECT.

L'optimiseur peut exécuter physiquement les opérations dans un autre ordre (filtrer avant de joindre, utiliser un index pour éviter un tri), mais le résultat est toujours celui de l'ordre logique.

Exercices

SELECT nom, prenom, date_embauche
FROM employe
WHERE date_embauche >= '2020-01-01' AND date_embauche < '2024-01-01'
ORDER BY date_embauche;

SELECT id_ticket, titre, priorite, statut
FROM ticket
WHERE statut <> 'resolu'
  AND priorite IN ('haute', 'critique')
ORDER BY id_ticket;

SELECT id_ticket, titre
FROM ticket
WHERE id_poste IS NULL
ORDER BY id_ticket;

SELECT num_inventaire, prix_achat
FROM poste
ORDER BY prix_achat, num_inventaire
LIMIT 4 OFFSET 8;

SELECT num_inventaire, DATEDIFF('2026-10-28', date_achat) AS age_jours
FROM poste
WHERE age_jours > 5 * 365
ORDER BY age_jours DESC;

SELECT num_inventaire, DATEDIFF('2026-10-28', date_achat) AS age_jours
FROM poste
WHERE DATEDIFF('2026-10-28', date_achat) > 5 * 365
ORDER BY age_jours DESC, num_inventaire;