LIMIT met een offset is extreem traag in de meeste databases (ik heb gevonden sommige documentatie hiertoe voor MySQL en ik probeer een echt goed artikel te vinden dat ik een tijdje geleden heb gelezen waarin dit wordt uitgelegd voor SQLite). De reden is dat het over het algemeen ongeveer als volgt wordt geïmplementeerd:
- Doe alle normale queryplanning alsof de
LIMITclausule was er niet - Doorloop de resultaten totdat we bij de gewenste index zijn
- Begin met het retourneren van resultaten
Wat betekent dit als u LIMIT 10000, 10 . doet , wordt het geïnterpreteerd als:
- Haal de eerste 10.000 resultaten op en negeer ze
- Geef je de volgende 10 resultaten
Er is een triviale optimalisatie waarbij je de index op zijn minst voor de eerste 10.000 resultaten kunt gebruiken, omdat je niet om hun waarden geeft, maar zelfs in dat geval moet de database nog steeds 10.000 indexwaarden doorlopen voordat je je 10 resultaten krijgt. Er kunnen verdere optimalisaties zijn die dit kunnen verbeteren, maar in het algemeen wil je geen gebruik maken van LIMIT met een offset voor grote waarden .
De meest efficiënte manier om paginering af te handelen die ik ken, is door de laatste index bij te houden, dus als pagina één eindigt op id = 5 en maak vervolgens uw volgende link hebben WHERE id > 5 (met een LIMIT x natuurlijk).
EDIT:het artikel voor SQLite gevonden . Ik raad je ten zeerste aan dit te lezen, omdat het The Right Way™ uitlegt om dingen in SQL te doen. Omdat de SQLite-mensen heel slim zijn en andere databases hebben hetzelfde probleem, ik neem aan dat MySQL dit op een vergelijkbare manier implementeert.