LIMIT avec un décalage est extrêmement lent dans la plupart des bases de données (j'ai trouvé certains documentation à cet effet pour MySQL et j'essaie de trouver un très bon article que j'ai lu il y a quelque temps expliquant cela pour SQLite). La raison en est qu'il est généralement implémenté quelque chose comme ceci :
- Faire toute la planification normale des requêtes comme si le
LIMITla clause n'était pas là - Parcourir les résultats jusqu'à ce que nous arrivions à l'index souhaité
- Commencez à renvoyer des résultats
Qu'est-ce que cela signifie si vous faites LIMIT 10000, 10 , il sera interprété comme :
- Récupérer les 10 000 premiers résultats et les ignorer
- Vous donner les 10 prochains résultats
Il y a une optimisation triviale où vous pouvez au moins utiliser l'index pour les 10 000 premiers résultats puisque vous ne vous souciez pas de leurs valeurs, mais même dans ce cas, la base de données doit encore parcourir 10 000 valeurs d'index avant de vous donner vos 10 résultats. Il peut y avoir d'autres optimisations qui peuvent améliorer cela, mais dans le cas général vous ne voulez pas utiliser LIMIT avec un décalage pour les grandes valeurs .
Le moyen le plus efficace de gérer la pagination que je connaisse est de garder une trace du dernier index, donc si la première page se termine sur id = 5 , puis faites votre suivant le lien a WHERE id > 5 (avec un LIMIT x bien sûr).
EDIT :Trouvé l'article pour SQLite . Je vous recommande fortement de lire ceci car il explique The Right Way™ pour faire les choses en SQL. Puisque les gens de SQLite sont vraiment intelligents et d'autres bases de données ont le même problème, je suppose que MySQL implémente cela de la même manière.
