Tabellen har en primær nøgle. Gør brug af det.
I stedet for LIMIT og OFFSET , lav din personsøgning med et filter på den primære nøgle. Du antydede dette med din kommentar:
Personsøgning ved hjælp af tilfældige tal (Tilføj "STØRRE END ORDER BY" til hver forespørgsel)
men der er ikke noget tilfældigt ved, hvordan du skal gøre det.
SELECT * FROM big_table WHERE id > $1 ORDER BY id ASC LIMIT $2
Tillad klienten at angive begge parametre, det sidste ID, den så, og antallet af poster, der skal hentes. Din API skal enten have en pladsholder, ekstra parameter eller alternativt kald for "hent den første n ID'er", hvor den udelader WHERE klausul fra forespørgslen, men det er trivielt.
Denne tilgang vil bruge en ret effektiv indeksscanning for at få posterne i orden, og generelt undgå en sortering eller behovet for at gentage alle de overspringede poster. Klienten kan bestemme, hvor mange rækker den vil have på én gang.
Denne tilgang adskiller sig fra LIMIT og OFFSET tilgang på én nøglemåde:samtidig modifikation. Hvis du INSERT ind i tabellen med en tast nedre end en nøgle, som nogle klienter allerede har set, vil denne tilgang slet ikke ændre sine resultater, mens OFFSET tilgang vil gentage en række. På samme måde, hvis du DELETE en række med et lavere-end-allerede set ID, vil resultaterne af denne tilgang ikke ændre sig, mens OFFSET springer en usynlig række over. Der er dog ingen forskel for tabeller, der kun kan tilføjes med genererede nøgler.
Hvis du på forhånd ved, at klienten vil have hele resultatsættet, er den mest effektive ting at gøre bare at sende dem hele resultatsættet uden noget af denne personsøgning. Det er der, jeg ville bruge en markør. Læs rækkerne fra DB'en og send dem til klienten så hurtigt som klienten vil acceptere dem. Denne API ville skulle sætte grænser for, hvor langsom klienten måtte være for at undgå overdreven backend-belastning; for en langsom klient ville jeg sandsynligvis skifte til paging (som beskrevet ovenfor) eller spoole hele markørresultatet ud til en midlertidig fil og lukke DB-forbindelsen.
Vigtige forbehold :
- Kræver en
UNIQUEbegrænsning /UNIQUEindeks ellerPRIMARY KEYat være pålidelig - Forskellig samtidig modifikationsadfærd for at begrænse/forskyde, se ovenfor