Read Committed („lesen, sobald bestätigt") ist eine der vier klassischen SQL-Isolationsebenen nach SQL-92: Read Uncommitted, Read Committed, Repeatable Read und Serializable. In vielen Datenbanksystemen ist sie die Standardeinstellung.
Regel: Nur Committetes lesen
Eine Transaktion auf der Stufe Read Committed liest ausschließlich Daten, die zum Zeitpunkt des Lesevorgangs von anderen Transaktionen bereits committet wurden. Damit sind Dirty Reads ausgeschlossen — niemand sieht unbestätigte Änderungen einer noch laufenden Transaktion, die später zurückgerollt werden könnte.
Erlaubte Anomalien
Read Committed verhindert keine Non-Repeatable Reads: Der zweite SELECT in derselben Transaktion kann andere Werte liefern als der erste, weil zwischen den Abfragen eine andere Transaktion committet hat. Auch Phantomprobleme (neue Zeilen, die in eine Ergebnismenge hineinwachsen) sind möglich. Die Stufe arbeitet also mit einem Statement-Snapshot, nicht mit einem Transaktions-Snapshot.
Umsetzungen
- PostgreSQL: Read Committed ist die Standard-Isolationsebene. Jede Anweisung erhält einen eigenen Snapshot der committeten Daten (MVCC); „Read Uncommitted" verhält sich faktisch wie Read Committed.
- SQL Server: Mit der Option READ_COMMITTED_SNAPSHOT ON (Standard in Azure SQL Database) laufen Reads über Row-Versioning statt über gemeinsame Sperren.
- MySQL InnoDB: Die Standardeinstellung ist Repeatable Read; Read Committed steht als abschwächende Alternative zur Verfügung.
Wann einsetzen?
Read Committed ist ein guter Allround-Standard: korrekt gegen unbestätigte Daten, ohne die Sperr- und Snapshot-Kosten strengerer Stufen. Wer innerhalb einer Transaktion eine stabile Sicht braucht, wählt Repeatable Read; wer Invarianten über Snapshot Isolation hinaus schützen muss, braucht Serializable. Grundlagen dazu finden sich unter Transaktion und ACID; Sperrkonflikte können wie immer einen Deadlock verursachen.