Tabulka má primární klíč. Využijte toho.
Místo LIMIT a OFFSET , proveďte stránkování pomocí filtru na primárním klíči. Naznačil jste to svým komentářem:
Stránkování pomocí náhodných čísel ( ke každému dotazu přidejte „VĚTŠÍ NEŽ OBJEDNAT PODLE“)
ale na tom, jak byste to měli udělat, není nic náhodného.
SELECT * FROM big_table WHERE id > $1 ORDER BY id ASC LIMIT $2
Umožněte klientovi zadat oba parametry, poslední ID, které viděl, a počet záznamů k načtení. Vaše rozhraní API bude muset mít buď zástupný symbol, další parametr nebo alternativní volání pro „načtení prvního n ID“, kde se vynechává WHERE klauzule z dotazu, ale to je triviální.
Tento přístup bude používat poměrně efektivní indexové skenování k uspořádání záznamů, obecně se vyhne řazení nebo nutnosti opakovat všechny přeskočené záznamy. Klient se může rozhodnout, kolik řádků chce najednou.
Tento přístup se liší od LIMIT a OFFSET přístup jedním klíčovým způsobem:souběžná modifikace. Pokud INSERT do tabulky pomocí klávesy dolů než klíč, který již některý klient viděl, tento přístup vůbec nezmění jeho výsledky, zatímco OFFSET přístup bude opakovat řadu. Podobně, pokud DELETE řádek s nižším než již viděným ID se výsledky tohoto přístupu nezmění, zatímco OFFSET přeskočí neviditelný řádek. Neexistuje však žádný rozdíl pro tabulky pouze pro připojení s vygenerovanými klíči.
Pokud předem víte, že klient bude chtít celou sadu výsledků, nejúčinnější je poslat mu celou sadu výsledků bez tohoto stránkování. To je místo, kde bych byla použijte kurzor. Přečtěte si řádky z DB a odešlete je klientovi tak rychle, jak je klient přijme. Toto API by muselo nastavit limity na to, jak pomalý klient mohl být, aby se zabránilo nadměrné zátěži backendu; u pomalého klienta bych pravděpodobně přešel na stránkování (jak je popsáno výše) nebo bych celý výsledek kurzoru zařadil do dočasného souboru a ukončil připojení k DB.
Důležitá upozornění :
- Vyžaduje
UNIQUEomezení /UNIQUEindex neboPRIMARY KEYbýt spolehlivý - Odlišné chování souběžné modifikace s limitem/offsetem, viz výše