LIMIT con un offset è estremamente lento nella maggior parte dei database (ho trovato alcuni documentazione in questo senso per MySQL e sto cercando di trovare un articolo davvero buono che ho letto tempo fa che lo spiega per SQLite). Il motivo è che generalmente viene implementato qualcosa del genere:
- Esegui tutta la normale pianificazione delle query come se fosse
LIMITla clausola non c'era - Esamina i risultati fino ad arrivare all'indice che desideri
- Inizia a restituire risultati
Cosa significa se si esegue LIMIT 10000, 10 , sarà interpretato come:
- Recupera i primi 10.000 risultati e ignorali
- Dai i prossimi 10 risultati
C'è un'ottimizzazione banale in cui puoi almeno utilizzare l'indice per i primi 10.000 risultati poiché non ti interessano i loro valori, ma anche in quel caso, il database deve comunque esaminare 10.000 valori di indice prima di darti i tuoi 10 risultati. Potrebbero esserci ulteriori ottimizzazioni che possono migliorare questo, ma nel caso generale non si desidera utilizzare LIMIT con un offset per grandi valori .
Il modo più efficiente per gestire l'impaginazione di cui sono a conoscenza è tenere traccia dell'ultimo indice, quindi se la prima pagina termina con id = 5 , quindi fai il tuo successivo il link ha WHERE id > 5 (con un LIMIT x ovviamente).
EDIT:trovato l'articolo per SQLite . Consiglio vivamente di leggere questo dato che spiega The Right Way™ per fare le cose in SQL. Dal momento che le persone di SQLite sono veramente intelligenti e altri database hanno lo stesso problema, presumo che MySQL lo implementi in modo simile.
