Her er, hvad jeg gjorde, og reducerede den samlede udførelsestid med en faktor på 10.
Det, jeg indså fra udførelsesplanen for min oprindelige forespørgsel, var, at den brugte filesort til at sortere alle resultater og ignorere indekserne. Det er lidt af et spild.
Min testdatabase:5 M poster, 20 GB størrelse. tabelstrukturen den samme som i spørgsmålet
I stedet for at få blobCol direkte i den første forespørgsel, får jeg først værdien af 'navn' for begyndelsen af hver side. Kør denne forespørgsel på ubestemt tid, indtil den returnerer 0 resultater. Hver gang skal du tilføje resultatet til en liste
SELECT name
FROM my_table
where id = <anyId> // I use the id column for partitioning so I need this here
order by name
limit <pageSize * pageNumber>, 1
Sinussidetal er ikke tidligere kendt, start med værdien 0 og fortsæt med at stige, indtil forespørgslen returnerer null. Du kan også foretage en udvalgt optælling(*), men det kan i sig selv tage lang tid og hjælper ikke med at optimere noget. Hver forespørgsel tog omkring 2 sekunder at køre, når sidetallet oversteg ~60.
For mig var sidestørrelsen 5000, så jeg fik en liste over 'navn'-strenge på position 0, 5001, 10001, 15001 og så videre. Antallet af sider viste sig at være 1000, og det er ikke dyrt at gemme en liste med 1000 resultater i hukommelsen.
Gentag nu listen og kør denne forespørgsel
SELECT blobCol
FROM my_table
where name >= <pageHeader>
and name < <nextPageHeader>
and city="<any string>"
and id= 1
Dette vil køre N gange, hvor N =størrelsen på listen opnået tidligere. Da 'navn' er den primære nøglekolonne, og 'by' også er indekseret, viser EXPLAIN, at denne beregning udføres i hukommelsen ved hjælp af indekset.
Nu tager hver forespørgsel 1 sekund at køre i stedet for de oprindelige 30-40. Så hvis man kombinerer forbehandlingstiden på 2 sekunder pr. side, er den samlede tid pr. side 3-4 sekunder i stedet for 30-40.
Hvis nogen har en bedre løsning, eller hvis der er noget åbenlyst galt med denne, så lad mig det vide