U kunt niet weten wat de eerste id op een bepaalde pagina is, omdat id-nummers niet noodzakelijk opeenvolgend zijn. Met andere woorden, er kunnen hiaten in de reeks zijn, dus rijen op de vijfde pagina van 100 rijen beginnen niet noodzakelijk bij id 500. Het kan bijvoorbeeld beginnen op id 527. Het is onmogelijk om te weten.
Nog een andere manier gezegd:id is een waarde, geen rijnummer.
Een mogelijke oplossing als uw klant in oplopende volgorde door pagina's bladert, is dat elk REST-verzoek gegevens ophaalt, noteert de grootste id-waarde op die pagina en gebruikt die vervolgens in de volgende REST-verzoek zodat het ID-waarden opvraagt die groter zijn.
SELECT ... FROM ... WHERE filterKey = filterValue
AND id > id_of_last_match_of_previous_page
Maar als uw REST-verzoek een willekeurige pagina kan ophalen, werkt deze oplossing niet. Het hangt ervan af of de vorige pagina al is opgehaald.
Een andere oplossing is het gebruik van de LIMIT <x> OFFSET <y> syntaxis. Hiermee kunt u elke willekeurige pagina opvragen. LIMIT <y>, <x> werkt hetzelfde, maar om de een of andere reden zijn x en y omgekeerd in de twee verschillende syntaxisvormen, dus houd daar rekening mee.
LIMIT...OFFSET gebruiken is niet erg efficiënt wanneer u een pagina opvraagt die veel pagina's in het resultaat bevat. Stel dat u de 5.000ste pagina opvraagt. MySQL moet aan de serverzijde een resultaat van 5.000 pagina's genereren, vervolgens 4.999 daarvan weggooien en de laatste pagina in het resultaat retourneren. Sorry, maar zo werkt het.
Over uw opmerking:
Je moet begrijpen dat WHERE past voorwaarden toe op waarden in rijen, maar pagina's worden gedefinieerd door de positie van rijen. Dit zijn twee verschillende manieren om rijen te bepalen!
Als u een kolom heeft die gegarandeerd een rijnummer is , dan kunt u die waarde gebruiken als een rijpositie. Je kunt er zelfs een index op zetten, of het als de primaire sleutel gebruiken.
Maar primaire sleutelwaarden kunnen veranderen en zijn mogelijk niet opeenvolgend, bijvoorbeeld als u rijen bijwerkt of verwijdert, of sommige transacties terugdraait, enzovoort. Het hernummeren van primaire sleutelwaarden is een slecht idee omdat andere tabellen of externe gegevens kunnen verwijzen naar primaire sleutelwaarden.
U kunt dus nog een kolom toevoegen die niet . is de primaire sleutel, maar alleen een rijnummer.
ALTER TABLE MyTable ADD COLUMN row_number BIGINT UNSIGNED, ADD KEY (row_number);
Vul vervolgens de waarden in wanneer u de rijen moet hernummeren.
SET @row := 0;
UPDATE MyTable SET row_number = (@row := @row + 1) ORDER BY id;
U moet de rijen bijvoorbeeld opnieuw nummeren als u er ooit een verwijdert. Het is niet efficiënt om dit vaak te doen, afhankelijk van de grootte van de tafel.
Nieuwe invoegingen kunnen ook geen juiste rijnummerwaarden maken zonder de tabel te vergrendelen. Dit is nodig om race-omstandigheden te voorkomen.
Als u zeker weet dat row_number is een reeks opeenvolgende waarden, dan is het zowel een waarde als een rijpositie, zodat u deze kunt gebruiken voor hoogwaardige indexzoekopdrachten voor elke willekeurige pagina met rijen.
SELECT * FROM MyTable WHERE row_number BETWEEN 401 AND 500;
In ieder geval tot de volgende keer dat de volgorde van rijnummers in twijfel wordt getrokken door een verwijdering of door nieuwe invoegingen.