Was sind Transaktionsisolationsstufen?

Question

Accepted Answer

**Isolationsstufen** kontrollieren, wie viel gleichzeitige Transaktionen von den uncommitted (oder laufenden) Änderungen anderer sehen können — sie handeln **Konsistenz** gegen **Leistung/Parallelität** ab. Höhere Isolation verhindert mehr Anomalien, erhöht aber Locking/Contention.

## Concurrency-Anomalien (was Isolation verhindert)

```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)
```

Dies sind die Probleme, die auftreten können, wenn Transaktionen gleichzeitig laufen — Isolationsstufen kontrollieren, welche verhindert werden.

## Die vier Standard-Isolationsstufen

Jede höhere Stufe verhindert mehr Anomalien. **Read Committed** ist ein häufiger Standard (verhindert Dirty Reads); **Serializable** ist das strengste (Transaktionen verhalten sich, als würden sie nacheinander laufen), aber am restriktivsten für Parallelität.

## Festlegen der Isolationsstufe

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

## Der grundlegende Trade-off

```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.).
```

## Warum es wichtig ist

Transaktionsisolationsstufen sind wichtiges fortgeschrittenes Wissen für das Verständnis von **Parallelität in Datenbanken** — wenn mehrere Transaktionen gleichzeitig laufen (wie in jeder echten Multi-User-Anwendung), bestimmen Isolationsstufen den Trade-off zwischen Datenkonsistenz und Leistung, daher ist das Verständnis dafür wertvoll für den Aufbau korrekter, performanter paralleler Anwendungen.

Die Kernkonzepte sind die **Concurrency-Anomalien** (Dirty Reads, Non-Repeatable Reads, Phantom Reads — die Probleme, die entstehen, wenn Transaktionen laufende Änderungen anderer sehen) und wie die **vier Isolationsstufen** (Read Uncommitted, Read Committed, Repeatable Read, Serializable) progressiv mehr davon verhindern.

Das Verständnis ist wichtig für Korrektheit: Eine zu niedrige Isolationsstufe wählen kann Anomalien zulassen, die Daten beschädigen oder falsche Ergebnisse liefern (z.B. uncommitted Data lesen, die später zurückgerollt wird, oder inkonsistente Lesevorgänge), während zu hohe Werte die Parallelität und Leistung reduzieren.

Der **grundlegende Trade-off** — höhere Isolation bedeutet mehr Korrektheit, aber mehr Locking/Contention (niedrigere Parallelität, potenzielle Verlangsamungen und Deadlocks), niedrigere Isolation bedeutet mehr Leistung, aber Risiko von Anomalien — ist die Haupterkenntnis: Sie wählen die Stufe basierend auf den Konsistenzanforderungen der Daten (kritische/finanzielle Daten benötigen möglicherweise Serializable; die meisten Anwendungen verwenden Read Committed als Balance).

Zu wissen, dass Implementierungen unterschiedlich sind (MVCC vs Locking) ist auch relevant.

Da Parallelität in echten Datenbankanwendungen inhärent ist und Isolationsstufen die kritische Balance zwischen Konsistenz und Leistung steuern (wobei falsche Wahlen entweder Datienanomolien oder Leistungsprobleme verursachen), ist das Verständnis von Isolationsstufen — die Anomalien, die Stufen und der Konsistenz-vs-Parallelität Trade-off — wertvolles Senior-Level-Wissen für den Aufbau korrekter, performanter paralleler Systeme und ein häufiges fortgeschrittenes Interview-Thema, das das Verständnis von Datenbank-Parallelität demonstriert.