Réponse.

La pagination (affichage page par page) permet de traiter de grands résultats SELECT sans surcharger le serveur et l'application. Les principales approches :

• LIMIT/OFFSET — pratique, mais peu réactive avec de grands OFFSET.
• Keyset pagination (méthode Seek) — basée sur la valeur d'un champ unique/triable (par exemple, id ou timestamp), beaucoup plus performante lors d'une navigation "profonde".

Exemple (LIMIT/OFFSET)

SELECT * FROM Orders
ORDER BY OrderID
LIMIT 100 OFFSET 1000;

Cette requête retourne les enregistrements 1011 à 1110. Cependant, OFFSET oblige le serveur à trier et à ignorer les 1000 premières lignes, ce qui rend la pagination profonde lente.

Exemple (Keyset/méthode Seek)

SELECT * FROM Orders
WHERE OrderID > 1110
ORDER BY OrderID
LIMIT 100;

Cette requête trouve rapidement la page suivante sans consommer de ressources pour calculer l'OFFSET, particulièrement efficace en présence d'un index sur OrderID.

Question piège.

Piège : "Pourquoi la pagination avec LIMIT/OFFSET peut-elle mal fonctionner avec de grands volumes de données et comment l'améliorer ?"

Réponse : La difficulté réside dans le fait que OFFSET nécessite que le serveur parcourt et trie toutes les lignes précédentes — donc plus on descend dans les pages, plus cela devient lent. L'optimisation consiste à passer à la pagination keyset/seek : choisir non pas par décalage, mais par la clé du dernier enregistrement de la page précédente.

-- Obtenir la page suivante par clé
SELECT * FROM Orders WHERE OrderID > @LastOrderID ORDER BY OrderID LIMIT 100;

Exemples d'erreurs réelles dues à un manque de connaissance des subtilités du sujet.

---

Histoire

Projet : Marché en ligne, base des commandes sur 5 ans (50 millions de lignes)

Erreur : Utilisation de OFFSET pour la pagination des commandes des anciens utilisateurs. Les requêtes avec OFFSET > 1 million commençaient à prendre 30 à 60 secondes. Cela a affecté les rapports et l'API — ce qui a entraîné une surcharge CPU des serveurs et une augmentation du temps d'attente dans la file d'attente.

---

---

Histoire

Projet : CRM d'entreprise, rapports sur les clients.

Erreur : Dans la pagination, la méthode de tri n'était pas prise en compte et les index n'étaient pas utilisés. Cela entraînait une baisse de performance et un contrôle d'intégrité des échantillons — les utilisateurs recevaient les mêmes lignes sur différentes pages lors de changements dans la table.

---

---

Histoire

Projet : Plateforme financière, tableaux de bord.

Erreur : Les paginations complexes étaient construites via SQL dynamique généré sans variables bind, ce qui a conduit à des injections SQL et à des problèmes de support de la transactionnalité entre les pages de données.

---