Jak działają ORDER BY i LIMIT oraz jak się implementuje paginację?

Question

Accepted Answer

**`ORDER BY`** sortuje wiersze wyników; **`LIMIT`** (z `OFFSET`) ogranicza liczbę zwracanych wierszy. Razem obsługują sortowanie i paginację — niezbędne do wyświetlania posortowanych, podzielonych na strony danych.

## ORDER BY — sortowanie

```sql
SELECT name, age FROM users ORDER BY age;            -- ascending (default)
SELECT name, age FROM users ORDER BY age DESC;        -- descending
SELECT * FROM users ORDER BY country, name;           -- by country, then name (tie-break)
SELECT * FROM users ORDER BY created_at DESC NULLS LAST;  -- control NULL placement
```

`ORDER BY` sortuje po jednej lub więcej kolumnach, rosnąco (domyślnie) lub `DESC`. Wiele kolumn zapewnia rozbijanie remisów (sortowanie po pierwszej, następnie po drugiej dla równych wartości).

## LIMIT i OFFSET — ograniczanie i paginacja

```sql
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` zwraca co najwyżej `n` wierszy; `OFFSET m` pomija pierwsze `m`. Razem implementują **paginację opartą na offsetcie** (strona N = `LIMIT rozmiarStrony OFFSET (N-1)*rozmiarStrony`).

## Zawsze używaj ORDER BY podczas paginacji

```sql
-- ❌ 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;
```

**Krytyczne:** bez `ORDER BY` baza danych może zwrócić wiersze w dowolnej kolejności, więc strony mogą się nakładać lub pomijać wiersze. Zawsze sortuj po stabilnej kolumnie podczas paginacji.

## Paginacja OFFSET staje się wolna na głębokich stronach

```text
⚠️ 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
```

## Dlaczego to ważne

`ORDER BY` i `LIMIT` są fundamentalne do wyświetlania danych w użyteczny, zarządzalny sposób — sortowanie wyników i zwracanie stron zamiast całych tabel jest prawie uniwersalną potrzebą (każda lista, tabela lub kanał informacyjny w aplikacji), więc ich zrozumienie jest niezbędną codzienną wiedzą. `ORDER BY` (sortowanie po jednej lub więcej kolumnach z rozbijaaniem remisów) jest niezbędne do przedstawiania danych w sensownej kolejności, a `LIMIT`/`OFFSET` implementują **paginację** (zwracanie zarządzalnych stron danych) — obie wszechobecne w aplikacjach.

Dwa praktyczne punkty są szczególnie ważne: **zawsze używaj `ORDER BY` podczas paginacji** (bez niego, kolejność wierszy jest niezdefiniowana, powodując niespójne strony, które nakładają się lub pomijają wiersze — rzeczywisty, częsty błąd) oraz zrozumienie, że **paginacja OFFSET pogarsza się na głębokich stronach** (baza danych musi pominąć wszystkie poprzednie wiersze, co spowalnia dla dużych offsetów), więc **paginacja kluczowa/kursorowa** (`WHERE id > ostatnio_widziany`) jest znacznie bardziej wydajna dla dużych zbiorów danych — cenna wiedza dla wydajności.

Ponieważ sortowanie i paginacja są wymagane dla praktycznie każdego wyświetlania danych, a ponieważ wymóg spójności (ORDER BY dla stabilnej paginacji) i rozważanie wydajności (OFFSET vs paginacja kluczowa dla dużych danych) bezpośrednio wpływają na poprawność i szybkość, opanowanie `ORDER BY` i `LIMIT` — sortowania, paginacji opartej na offsetcie, wymogu stabilnego uporządkowania i alternatywy kluczowej dla skalowania — jest podstawową, często stosowaną wiedzą do budowania aplikacji, które efektywnie prezentują dane.