MySQL-forespørgsel med grænse og stor offset, der tager evigheder

LIMIT med en offset er ekstremt langsom i de fleste databaser (jeg har fundet nogle dokumentation til denne effekt for MySQL, og jeg forsøger at finde en rigtig god artikel, som jeg læste for et stykke tid siden, og som forklarer dette for SQLite). Årsagen er, at det generelt er implementeret noget som dette:

1. Udfør al normal forespørgselsplanlægning, som om LIMIT klausul var der ikke
2. Gennemgå resultaterne, indtil vi når det indeks, du ønsker
3. Begynd at returnere resultater

Hvad betyder det, hvis du gør LIMIT 10000, 10 , vil det blive fortolket som:

1. Hent de første 10.000 resultater, og ignorer dem
2. Giv dig de næste 10 resultater

Der er en triviel optimering, hvor du i det mindste kan bruge indekset til de første 10.000 resultater, da du er ligeglad med deres værdier, men selv i det tilfælde skal databasen stadig gennemgå 10.000 indeksværdier, før du giver dig dine 10 resultater. Der kan være yderligere optimeringer, der kan forbedre dette, men i det generelle tilfælde ønsker du ikke at bruge LIMIT med en offset for store værdier .

Den mest effektive måde at håndtere paginering på, som jeg er opmærksom på, er at holde styr på det sidste indeks, så hvis side et slutter på id = 5 , og lav derefter din næste linket har WHERE id > 5 (med en LIMIT x selvfølgelig).

EDIT:Fandt artiklen til SQLite . Jeg anbefaler stærkt, at du læser dette, da det forklarer The Right Way™ at gøre ting i SQL. Da SQLite-folkene er virkelig smarte og andre databaser har det samme problem, antager jeg, at MySQL implementerer dette på en lignende måde.