ORDER BY, LIMIT, OFFSET

ORDER BY — Reihenfolge

Mit ORDER BY legst du fest, in welcher Reihenfolge das Resultset zurückkommt. Du kannst nach mehreren Spalten gleichzeitig sortieren:

SELECT id, total, created_at
FROM orders
ORDER BY total DESC, created_at ASC, id ASC;

Hier sortieren wir die Bestellungen nach drei Kriterien:

1. zuerst nach total absteigend (höchste Beträge oben),
2. bei gleichem Betrag nach created_at aufsteigend (älteste zuerst),
3. bei gleichem Betrag und identischem Zeitstempel nach id aufsteigend (Tiebreaker).

ASC (= ascending, aufsteigend) ist der Default; DESC (= descending) muss explizit hingeschrieben werden. Mehrere Spalten werden lexikographisch verglichen — erst nach der ersten, bei Gleichstand nach der zweiten, usw.

ORDER BY kann auch:

• Spalten-Position: ORDER BY 2, 3 — sortiert nach 2. und 3. SELECT-Spalte. Praktisch in Ad-hoc-Queries, gefährlich in Production (Reihenfolge der SELECT-Liste ändert die Sort-Logik).
• Aliasse aus SELECT: SELECT total*1.19 AS total_incl_tax … ORDER BY total_incl_tax. Funktioniert in ORDER BY (anders als in WHERE).
• Beliebige Ausdrücke: ORDER BY length(name), name.

NULL und die Reihenfolge

ORDER BY muss eine Entscheidung treffen, wo NULL-Werte landen. Postgres-Default:

• ASC → NULLS LAST (NULLs am Ende)
• DESC → NULLS FIRST (NULLs am Anfang)

Das ist die Konvention „NULL als unbekannt / fehlend → ans Ende der bekannten Werte”. Explizit überschreiben:

SELECT * FROM orders
ORDER BY shipped_at ASC NULLS FIRST;

Das ist nützlich für „pending oben, abgeschlossene unten”-Listen.

LIMIT — kürzen

SELECT id, total
FROM orders
ORDER BY created_at DESC
LIMIT 10;

LIMIT n schneidet bei n Zeilen ab. Postgres optimiert das oft schon im Plan: bei einem Index auf created_at muss nicht die ganze Tabelle gelesen werden, sondern nur die ersten 10 Zeilen.

LIMIT ALL (oder Weglassen) → keine Begrenzung. LIMIT 0 → null Zeilen (für Schema-Inspection praktisch).

OFFSET — und warum es teuer wird

SELECT id, total
FROM orders
ORDER BY created_at DESC
LIMIT 20 OFFSET 100;

Klassische Pagination-Form. Funktioniert — bis die Tabelle groß wird.

Das Problem: Postgres muss die ersten 100 Zeilen trotzdem lesen (sortiert), um sie zu überspringen. Bei OFFSET 10000 werden 10.020 Zeilen verarbeitet, davon 10.000 weggeworfen. Das ist linear schlechter, je tiefer man in die Pagination geht.

Plus: ein neuer Eintrag in orders während der Pagination kann Zeilen verschieben — eine Zeile auf Seite 5 erscheint plötzlich auf Seite 6, oder doppelt.

Keyset-Pagination — die saubere Alternative

Statt nach Offset, nach Wert der Sort-Spalte paginieren:

SELECT id, total, created_at
FROM orders
ORDER BY created_at DESC, id DESC
LIMIT 20;

Die letzte Zeile dieser Seite hat z. B. created_at = '2026-05-01 12:00', id = 100. Nächste Seite:

SELECT id, total, created_at
FROM orders
WHERE (created_at, id) < ('2026-05-01 12:00', 100)
ORDER BY created_at DESC, id DESC
LIMIT 20;

Der Trick: das Tupel-Vergleichs-Konstrukt (a, b) < (x, y) macht lexikographischen Vergleich — erst a < x, bei Gleichheit b < y. Mit Index auf (created_at, id) ist das ein einziger Index-Lookup, unabhängig davon, wie tief in der Pagination wir sind.

Vorteile:

• Konstante Performance — Seite 1.000 ist genauso schnell wie Seite 1.
• Konsistent bei nebenläufigen Inserts — keine doppelten oder übersprungenen Zeilen.

Nachteile:

• Kein direkter Sprung zu „Seite 5” möglich — Pagination ist nur „nächste/vorherige”.
• Braucht Cursor-Werte beim Client (oder URL).

Pragmatisch: für Endless-Scroll-/Feed-UIs ist Keyset perfekt. Für klassische Seiten-Navigation („Seite 5 von 200”) muss man entweder mit OFFSET leben oder ein Hybrid-Pattern bauen (Sprung-Seiten plus Keyset zwischen ihnen).

Total-Count und Pagination

Häufige Anforderung: „Seite 5 von 200” zeigen — also die Gesamtzahl. Bei großen Tabellen ist SELECT count(*) selbst eine teure Query (Sequential Scan über alles).

Drei Strategien:

SELECT id, total,
       count(*) OVER () AS total_count
FROM orders
WHERE status = 'paid'
ORDER BY created_at DESC
LIMIT 20 OFFSET 100;

SELECT reltuples::bigint AS approximate_count
FROM pg_class
WHERE relname = 'orders';

Praxis-Beispiele

Stable Sort mit Tiebreaker

SELECT id, total, created_at
FROM orders
ORDER BY total DESC, id ASC   -- Tiebreaker: id
LIMIT 20;

Ohne den id-Tiebreaker ist die Sortierung bei gleichen total-Werten nicht deterministisch — gleiche Zeilen können bei jedem Aufruf in anderer Reihenfolge landen. Deswegen für Pagination: immer eine eindeutige Tiebreaker-Spalte (typisch id oder Primary Key).

Keyset-Pagination — kompletter Workflow

myapp=> SELECT id, total, created_at
        FROM orders
        ORDER BY created_at DESC, id DESC
        LIMIT 5;

 id  | total |       created_at
-----+-------+------------------------
 142 | 99.95 | 2026-05-06 11:32:17+00
 141 | 49.95 | 2026-05-06 10:15:00+00
 140 | 19.95 | 2026-05-06 09:08:42+00
 139 | 79.95 | 2026-05-06 08:00:00+00
 138 | 29.95 | 2026-05-05 22:45:11+00

Die letzte Zeile speichert der Client als Cursor: (2026-05-05 22:45:11+00, 138). Nächste Seite:

myapp=> SELECT id, total, created_at
        FROM orders
        WHERE (created_at, id) < ('2026-05-05 22:45:11+00', 138)
        ORDER BY created_at DESC, id DESC
        LIMIT 5;

 id  | total |       created_at
-----+-------+------------------------
 137 | 59.95 | 2026-05-05 18:30:00+00
 136 | 39.95 | 2026-05-05 17:00:00+00
 135 | 89.95 | 2026-05-05 14:22:00+00
 134 | 49.95 | 2026-05-05 11:11:11+00
 133 | 29.95 | 2026-05-04 23:58:00+00

Mit einem Index auf (created_at DESC, id DESC) ist das ein einziger Index-Lookup — Seite 100 ist genauso schnell wie Seite 1.

Total-Count nebenbei

SELECT
    id, total, status,
    count(*) OVER () AS total_count
FROM orders
WHERE status = 'paid'
ORDER BY created_at DESC
LIMIT 20 OFFSET 100;

Der total_count ist in jeder Zeile gleich — Postgres berechnet ihn einmal und füllt ihn ein. Spart eine zweite Query, kostet aber: alle gefilterten Zeilen werden trotzdem gelesen, weil OVER () ohne Partition über das gesamte Result läuft.

Weiterführende Ressourcen

Externe Quellen

• SELECT – ORDER BY
• SELECT – LIMIT/OFFSET
• Use The Index, Luke! – Pagination
• Window Functions – count(*) OVER ()

Verwandte Artikel

• SELECT und WHERE
• NULL und Three-Valued Logic
• INSERT, UPDATE, DELETE