Tabellen har en primärnyckel. Använd det.
Istället för LIMIT och OFFSET , gör din personsökning med ett filter på primärnyckeln. Du antydde detta med din kommentar:
Personsökning med slumpmässiga siffror (Lägg till "STÖRRE ÄN BESTÄLLNING AV " till varje fråga )
men det är inget slumpmässigt med hur du ska göra.
SELECT * FROM big_table WHERE id > $1 ORDER BY id ASC LIMIT $2
Tillåt klienten att ange båda parametrarna, det senaste ID som den såg och antalet poster som ska hämtas. Ditt API måste antingen ha en platshållare, extra parameter eller alternativt anrop för "hämta den första n IDs" där den utelämnar WHERE klausul från frågan, men det är trivialt.
Detta tillvägagångssätt kommer att använda en ganska effektiv indexskanning för att få ordning på posterna, i allmänhet undviker sortering eller behovet av att iterera igenom alla överhoppade poster. Klienten kan bestämma hur många rader den vill ha samtidigt.
Detta tillvägagångssätt skiljer sig från LIMIT och OFFSET strategi på ett nyckelsätt:samtidig modifiering. Om du INSERT in i tabellen med en tangent nedre än en nyckel som vissa klienter redan har sett, kommer detta tillvägagångssätt inte att ändra sina resultat alls, medan OFFSET tillvägagångssätt kommer att upprepa en rad. På samma sätt, om du DELETE en rad med ett lägre ID än vad som redan har setts kommer resultaten av denna metod inte att ändras, medan OFFSET kommer att hoppa över en osynlig rad. Det är dock ingen skillnad för tabeller som endast kan läggas till med genererade nycklar.
Om du i förväg vet att kunden kommer att vilja ha hela resultatuppsättningen, är det mest effektiva att göra att bara skicka hela resultatuppsättningen till dem utan någon av denna personsökningsverksamhet. Det är där jag skulle använd en markör. Läs raderna från DB och skicka dem till klienten så snabbt som klienten accepterar dem. Detta API skulle behöva sätta gränser för hur långsam klienten fick vara för att undvika överdriven belastning av backend; för en långsam klient skulle jag förmodligen byta till personsökning (som beskrivits ovan) eller spoola hela markörresultatet till en temporär fil och stänga DB-anslutningen.
Viktiga varningar :
- Kräver en
UNIQUEconstraint /UNIQUEindex ellerPRIMARY KEYatt vara pålitlig - Olika samtidiga modifieringsbeteende för att begränsa/förskjuta, se ovan