SQL: Spørringer, indeksering og ytelse i PostgreSQL

SQL er det mest undervurderte verktøyet i stacken min. Det er lett å behandle databasen som en dum lagringsboks — SELECT * FROM users WHERE id = ? — men forskjellen mellom en naiv spørring og en gjennomtenkt en kan være sekunder vs. millisekunder i produksjon.

Jeg bruker PostgreSQL via Supabase i flere prosjekter, inkludert Nextbook. Der har jeg lært å tenke på SQL som ytelsesverktøy, ikke bare datahenting.

Når CTEer gir mening

Common Table Expressions (CTEer) gjør komplekse spørringer lesbare. Istedenfor nestede subqueries som ingen forstår tre måneder senere, bryter jeg opp logikken i navngitte steg. Men CTEer er ikke gratis — PostgreSQL materialiserer dem som standard, noe som betyr at de kjøres fullt ut selv om du bare trenger noen rader. For ytelseskritiske spørringer bruker jeg NOT MATERIALIZED for å la planleggeren optimalisere.

Indekseringsstrategi

Den viktigste leksjonen: indekser er ikke noe du legger til etter at ting er tregt. De er en del av skjemadesignet. I Nextbook indekserer jeg kolonner som filtreres på — user_id, status, created_at — og bruker sammensatte indekser der spørringer filtrerer på flere kolonner samtidig.

EXPLAIN ANALYZE er verktøyet som avslører alt. Det viser ikke bare hva planleggeren tenker den skal gjøre, men hva som faktisk skjer — sequential scans der det burde vært index scans, uventede sort-operasjoner, eller joins som eksploderer i størrelse.

Eksempel: Optimalisert spørring med CTE og indeks

CREATE INDEX idx_books_user_status ON books (user_id, status, created_at DESC);

WITH recent_activity AS (
  SELECT book_id, MAX(updated_at) AS last_update
  FROM reading_progress
  WHERE user_id = $1 AND updated_at > NOW() - INTERVAL '30 days'
  GROUP BY book_id
)
SELECT b.id, b.title, b.status, ra.last_update
FROM books b
JOIN recent_activity ra ON ra.book_id = b.id
WHERE b.user_id = $1 AND b.status IN ('reading', 'paused')
ORDER BY ra.last_update DESC
LIMIT 20;

CTEen isolerer aktivitetslogikken, den sammensatte indeksen sørger for at filtreringen på user_id og status er rask, og LIMIT forhindrer at store resultatsett overføres unødvendig.

Oppsummering

SQL handler om å forstå hva databasen faktisk gjør med spørringen din. Bruk EXPLAIN ANALYZE som en vane, tenk på indekser fra starten, og bruk CTEer for lesbarhet — men vær bevisst på ytelseskostnaden.

Del av en serie med tekniske guider der jeg går gjennom verktøyene og teknologiene jeg bruker i praksis.