ORDER BY trie les lignes du résultat ; LIMIT (avec OFFSET) restreint le nombre de lignes retournées. Ensemble, ils gèrent le tri et la pagination — essentiels pour afficher des données triées et paginées.
name, age users age;
name, age users age ;
users country, name;
users created_at ;
ORDER BY trie selon une ou plusieurs colonnes, en ordre croissant (par défaut) ou DESC. Plusieurs colonnes permettent la résolution des égalités (trier d'abord par la première, puis par la deuxième pour les valeurs égales).
SELECT * FROM users ORDER BY name LIMIT 10; -- the first 10 rows
SELECT * FROM users ORDER BY name LIMIT 10 OFFSET 20; -- skip 20, take 10 (page 3)
-- (syntax varies: MySQL/Postgres use LIMIT/OFFSET; SQL Server uses TOP / OFFSET-FETCH)
LIMIT n retourne au maximum n lignes ; OFFSET m ignore les m premières. Ensemble, ils implémentent la pagination par offset (page N = LIMIT pageSize OFFSET (N-1)*pageSize).
-- ❌ LIMIT without ORDER BY → row order is UNDEFINED (inconsistent pages!)
SELECT * FROM users LIMIT 10;
-- ✅ always ORDER BY a stable column for consistent pagination
SELECT * FROM users ORDER BY id LIMIT 10;
Crucial : sans ORDER BY, la base de données peut retourner les lignes dans n'importe quel ordre, les pages peuvent donc se chevaucher ou sauter des lignes. Toujours trier par une colonne stable lors de la pagination.
⚠️ LIMIT 10 OFFSET 1000000 — the DB must SKIP a million rows first (slow on deep pages).
For large datasets, KEYSET (cursor) pagination is far more efficient:
WHERE id > :last_seen_id ORDER BY id LIMIT 10 -- uses an index, no skipping
ORDER BY et LIMIT sont fondamentaux pour afficher les données de manière utile et gérable — trier les résultats et retourner des pages plutôt que des tables entières est un besoin quasi universel (toute liste, tableau ou flux dans une application), comprendre ces concepts est donc essentiel pour le travail quotidien. ORDER BY (tri selon une ou plusieurs colonnes, avec résolution des égalités) est nécessaire pour présenter les données dans un ordre significatif, et LIMIT/OFFSET implémentent la pagination (retourner des pages gérables de données) — tous deux omniprésents dans les applications.
Deux points pratiques sont particulièrement importants : toujours utiliser ORDER BY lors de la pagination (sans lui, l'ordre des lignes est indéfini, causant des pages incohérentes qui se chevauchent ou sautent des lignes — un vrai bug courant), et comprendre que la pagination par OFFSET se dégrade sur les pages profondes (la base de données doit sauter toutes les lignes précédentes, ce qui ralentit pour les grands offsets), donc la pagination par keyset/cursor (WHERE id > last_seen) est bien plus efficace pour les grands ensembles de données — une connaissance précieuse pour la performance.
Since le tri et la pagination sont requis pour virtuellement tout affichage de données, et puisque le besoin de cohérence (ORDER BY pour une pagination stable) et la considération de performance (OFFSET vs keyset pour les grandes données) affectent directement la correction et la vitesse, maîtriser ORDER BY et LIMIT — tri, pagination par offset, le besoin d'ordre stable, et l'alternative keyset pour la scalabilité — est une connaissance fondamentale et fréquemment appliquée pour construire des applications qui présentent les données efficacement.