ORDER BY sorterer resultatradene; LIMIT (med OFFSET) begrenser hvor mange rader som returneres. Sammen håndterer de sortering og paginering — essensielt for å vise ordnede, paginarede data.
name, age users age;
name, age users age ;
users country, name;
users created_at ;
ORDER BY sorterer etter en eller flere kolonner, stigende (standard) eller DESC. Flere kolonner gir utjevning (sorter etter den første, deretter den andre for like verdier).
SELECT * FROM users ORDER BY name LIMIT 10; -- the first 10 rows
SELECT * FROM users ORDER BY name LIMIT 10 OFFSET 20; -- skip 20, take 10 (page 3)
-- (syntax varies: MySQL/Postgres use LIMIT/OFFSET; SQL Server uses TOP / OFFSET-FETCH)
LIMIT n returnerer maksimalt n rader; OFFSET m hopper over de første m. Sammen implementerer de offset-paginering (side N = LIMIT pageSize OFFSET (N-1)*pageSize).
-- ❌ LIMIT without ORDER BY → row order is UNDEFINED (inconsistent pages!)
SELECT * FROM users LIMIT 10;
-- ✅ always ORDER BY a stable column for consistent pagination
SELECT * FROM users ORDER BY id LIMIT 10;
Kritisk: uten ORDER BY kan databasen returnere rader i hvilken som helst rekkefølge, så sider kan overlappe eller hoppe over rader. Sorter alltid etter en stabil kolonne når du paginerer.
⚠️ LIMIT 10 OFFSET 1000000 — the DB must SKIP a million rows first (slow on deep pages).
For large datasets, KEYSET (cursor) pagination is far more efficient:
WHERE id > :last_seen_id ORDER BY id LIMIT 10 -- uses an index, no skipping
ORDER BY og LIMIT er grunnleggende for å vise data på en nyttig, håndterbar måte — sortering av resultater og returnering av sider i stedet for hele tabeller er et nesten universelt behov (hvilken som helst liste, tabell eller feed i en applikasjon), så å forstå dem er essensielt daglig kunnskapsgrunnlag. ORDER BY (sortering etter en eller flere kolonner, med utjevning) er nødvendig for å presentere data i en meningsfull rekkefølge, og LIMIT/OFFSET implementerer paginering (returnering av håndterbare sider med data) — begge allestedsnærværende i applikasjoner.
To praktiske poenger er særlig viktige: bruk alltid ORDER BY når du paginerer (uten det er radrekkefølgen udefinert, noe som forårsaker inkonsistente sider som overlapper eller hopper over rader — en reell, vanlig feil), og forståelse av at OFFSET-paginering forverres på dype sider (databasen må hoppe over alle foregående rader, blir treg for store offsets), så keyset/cursor-paginering (WHERE id > last_seen) er langt mer effektiv for store datasett — verdifull kunnskap for ytelse.
Ettersom sortering og paginering er nødvendig for praktisk talt enhver datakomplettvisning, og siden konsistenskravet (ORDER BY for stabil paginering) og ytelseshensyn (OFFSET vs keyset for store data) direkte påvirker korrekthet og hastighet, er det å beherske ORDER BY og LIMIT — sortering, offset-paginering, kravet om stabil rekkefølge, og keyset-alternativet for skalering — kjernekunnskap som brukes hyppig for å bygge applikasjoner som presenterer data effektivt.