Eine Transaktion fasst Anweisungen zu einer atomaren Einheit zusammen: Entweder committen alle oder alle werden zurückgerollt, was das A, C, I, D von ACID ergibt. Die Isolationsstufe stellt das "I" ein — wie viel gleichzeitige Transaktionen von den nicht committeten oder sich ändernden Daten der anderen sehen können.
| Stufe | Dirty Read | Non-repeatable Read | Phantom |
|---|---|---|---|
| READ UNCOMMITTED | möglich | möglich | möglich |
| READ COMMITTED | nein | möglich | möglich |
| REPEATABLE READ (InnoDB-Standard) | nein | nein | meist nein* |
| SERIALIZABLE | nein | nein | nein |
\*InnoDBs REPEATABLE READ nutzt MVCC (jede Transaktion liest einen konsistenten Snapshot) plus Next-Key-Locks, sodass es auch die meisten Phantoms blockiert — stärker, als der SQL-Standard verlangt.
SELECT @@transaction_isolation; -- REPEATABLE-READ by default
START TRANSACTION;
SELECT balance FROM accounts WHERE id = 1; -- snapshot taken here
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT; -- both updates apply, or ROLLBACK undoes both
Behalte den InnoDB-Standard (REPEATABLE READ), sofern du keinen Grund hast. READ COMMITTED (der Standard bei Postgres/Oracle) reduziert Sperrkonflikte bei schreibintensiven Systemen; SERIALIZABLE ist korrekt, serialisiert aber konfligierende Arbeit und kann häufiger zu Deadlocks führen.
Isolation ist der Regler zwischen Korrektheit und Nebenläufigkeit. Diese Anomalien zu verstehen erlaubt dir, Fehler wie "die Summe stimmte unter Last nicht" zu erklären und eine Stufe zu wählen, die geldbewegende Transaktionen korrekt hält, ohne den Durchsatz unnötig zu drosseln.
Eine Sammlung von IT-Interviewfragen mit ausführlichen Antworten — vom Junior bis zum Senior.
Spenden