Antwort

Transaktionsisolierung beeinflusst, wie gleichzeitige Transaktionen die Änderungen anderer Transaktionen sehen. Dies ist ein wichtiger Teil der ACID-Eigenschaften. Es gibt vier grundlegende Isolationsstufen in ANSI SQL:

• READ UNCOMMITTED — Sieht sogar nicht-committete Änderungen anderer Transaktionen (schmutzige Lesevorgänge, dirty reads).
• READ COMMITTED — Sieht nur committed Änderungen; verhindert schmutzige Lesevorgänge, erlaubt aber nicht-wiederholbare Lesevorgänge (non-repeatable reads).
• REPEATABLE READ — Dieselben Daten erscheinen in einer Transaktion unverändert. Vermeidet schmutzige und nicht-wiederholbare Lesevorgänge, aber phantome Lesevorgänge (phantom reads) können auftreten.
• SERIALIZABLE — Die strengste Stufe, Transaktionen sind vollständig isoliert, als ob sie nacheinander ausgeführt werden; beseitigt alle Arten von Anomalien.

Die Wahl des Niveaus hängt von den Anforderungen der Anwendung ab:

• Für Berichterstattung reicht häufig REPEATABLE READ oder höher;
• Für Hochlastsysteme ist der optimale Kompromiss READ COMMITTED;
• Für Finanzanwendungen — SERIALIZABLE, trotz der Verringerung der Leistung.

Beispiel:

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN;
-- Weitere SELECT-Anweisungen sehen "eingefrorene" Werte

Fangfrage

"Gewährleistet das Niveau REPEATABLE READ den Schutz vor phantomen Lesevorgängen in jeder Datenbank?"

Nein. In PostgreSQL und einigen anderen DBMS verhindert das Niveau REPEATABLE READ nur schmutzige und nicht-wiederholbare Lesevorgänge, bietet jedoch nicht unbedingt Schutz vor phantomen Lesevorgängen. In MySQL/InnoDB ist REPEATABLE READ im Wesentlichen SERIALIZABLE, aber in anderen DBMS nicht.

Beispiel:

-- In einer Transaktion lesen wir SELECT * FROM orders WHERE amount > 100;
-- In einer anderen Transaktion wird ein neuer Wert mit amount > 100 eingefügt und committet.
-- Die erste Transaktion wird bei einer wiederholten SELECT-Anweisung eine "phantomartige" Zeile sehen, wenn die Isolierung unter SERIALIZABLE liegt.

Beispiele für reale Fehler aufgrund unzureichenden Wissens über die Feinheiten des Themas

---

Geschichte

Ein Finanzdienst hat nur READ COMMITTED wegen der Leistung blockiert — der Benutzer sah einen Betrag, den ein anderer Prozess bereits geändert hatte, es gab Unterschiede im Saldo.

---

Geschichte

Im Hotelbuchungssystem gab es doppelte Buchungen desselben Zimmers — die Transaktionen isolierten nicht die Abfragen aktueller Buchungen, das Niveau war READ COMMITTED.

---

Geschichte

Übergang von MySQL zu PostgreSQL: Der Entwickler war es gewohnt, dass REPEATABLE READ vor Phantomen schützt, aber nach der Migration traten "hängende" Aufträge auf, die man bei wiederholten Anfragen innerhalb derselben Transaktion nicht erwartet hatte.