bearbetning av ett stort antal databasposter med personsökning saktar ner med tiden

Här är vad jag gjorde och minskade den totala körningstiden med en faktor 10.

Vad jag insåg från exekveringsplanen för min ursprungliga fråga var att den använde filesort för att sortera alla resultat och ignorera indexen. Det är lite av ett slöseri.

Min testdatabas:5 M poster, 20 GB storlek. tabellstrukturen samma som i frågan

Istället för att få blobCol direkt i den första frågan, får jag först värdet på 'namn' för början av varje sida. Kör den här frågan på obestämd tid tills den returnerar 0 resultat. Lägg till resultatet i en lista varje gång

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

Sinussidans nummer är inte känt tidigare, börja med värdet 0 och fortsätt att öka tills frågan returnerar null. Du kan också göra en vald räkning(*), men det kan ta lång tid och hjälper inte att optimera någonting. Varje fråga tog cirka 2 sekunder att köra när sidnumret översteg ~60.

För mig var sidstorleken 5000 så jag fick en lista med "namn"-strängar på position 0, 5001, 10001, 15001 och så vidare. Antalet sidor visade sig vara 1000 och att lagra en lista med 1000 resultat i minnet är inte dyrt.

Gå nu igenom listan och kör den här frågan

SELECT blobCol
FROM my_table
where name >= <pageHeader>
and name < <nextPageHeader>
and city="<any string>"
and id= 1

Detta kommer att köras N gånger, där N =storleken på listan som erhållits tidigare. Eftersom 'namn' är den primära nyckeln kol, och 'stad' också är indexerad, visar EXPLAIN att denna beräkning utförs i minnet med hjälp av indexet.

Nu tar varje fråga 1 sekund att köra, istället för den ursprungliga 30-40. Så om man kombinerar förbehandlingstiden på 2 sekunder per sida, blir den totala tiden per sida 3-4 sekunder istället för 30-40.

Om någon har en bättre lösning eller om det är något uppenbart fel med den här, vänligen meddela mig