Vad är transaktionsisolationsnivåer?

Question

Accepted Answer

**Isolationsnivåer** kontrollerar hur mycket samtidiga transaktioner kan se av varandras ej bekräftade (eller pågående) ändringar — och balanserar **konsekvens** mot **prestanda/samtidighet**. Högre isolation förhindrar fler anomalier men ökar låsning/konkurrens.

## Samtidighetsanomalier (vad isolation förhindrar)

```text
DIRTY READ        → reading another transaction's UNCOMMITTED changes (which may roll back)
NON-REPEATABLE READ → re-reading a row gives different values (another txn UPDATED it)
PHANTOM READ      → re-running a query returns different ROWS (another txn INSERTED/DELETED)
```

Dessa är problem som kan uppstå när transaktioner körs samtidigt — isolationsnivåer kontrollerar vilka som förhindras.

## De fyra standardisolationsnivåerna

Varje högre nivå förhindrar fler anomalier. **Read Committed** är en vanlig standard (förhindrar dirty reads); **Serializable** är den strängaste (transaktioner beter sig som om de körs en åt gången) men mest restriktiv för samtidighet.

## Ange isolationsnivån

```sql
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN;
  -- ... operations run at the chosen isolation ...
COMMIT;
```

## Den fundamentala avvägningen

```text
Higher isolation → MORE correctness (fewer anomalies), but MORE locking/contention
                   → lower concurrency, potential slowdowns, more deadlocks
Lower isolation  → MORE concurrency/performance, but risk of anomalies
→ Choose based on the data's needs: financial/critical data may need Serializable;
  most apps use Read Committed (the default) as a balance.
→ Note: implementations vary (MVCC vs locking); the SQL standard defines the levels
  but databases differ in details (Postgres, MySQL/InnoDB, etc.).
```

## Varför det spelar roll

Transaktionsisolationsnivåer är viktig avancerad kunskap för att förstå **samtidighet i databaser** — när flera transaktioner körs samtidigt (som de gör i alla verkliga flerpersonsapplikationer) bestämmer isolationsnivåerna avvägningen mellan datakonsistens och prestanda, så att förstå dem är värdefullt för att bygga korrekta, högpresterande samtidiga applikationer.

Kärnbegreppet är **samtidighetsanomalier** (dirty reads, non-repeatable reads, phantom reads — de problem som uppstår när transaktioner ser varandras pågående ändringar) och hur de **fyra isolationsnivåerna** (Read Uncommitted, Read Committed, Repeatable Read, Serializable) gradvis förhindrar fler av dem.

Att förstå detta är viktigt för korrekthet: att välja en för låg isolationsnivå kan tillåta anomalier som korrupterar data eller producerar fel resultat (t.ex. läsa ej bekräftad data som senare återställs, eller inkonsistenta läsningar), medan att välja för högt minskar samtidighet och prestanda.

Den **fundamentala avvägningen** — högre isolation betyder mer korrekthet men mer låsning/konkurrens (lägre samtidighet, potentiella långsammare prestanda och deadlocks), lägre isolation betyder bättre prestanda men risk för anomalier — är den viktigaste insikten: du väljer nivå baserat på datans konsistensbehov (kritisk/finansiell data kan behöva Serializable; de flesta applikationer använder Read Committed som en balans).

Att veta att implementeringar varierar (MVCC kontra låsning) är också relevant.

Eftersom samtidighet är inneboende i verkliga databasapplikationer, och eftersom isolationsnivåer styr den kritiska balansen mellan konsistens och prestanda (där fel val orsakar antingen dataanomalier eller prestandaproblem), är förståelse av isolationsnivåer — anomalierna, nivåerna och konsistens-mot-samtidighet-avvägningen — värdefull kunskap på seniornivå för att bygga korrekta, högpresterande samtidiga system och ett vanligt avancerat intervjuämne som visar förståelse för databassamtidighet.