Entscheidung: Welche Isolationsstufe?
Die Isolationsstufe einer Transaktion bestimmt das Gleichgewicht zwischen Parallelität und Konsistenz. Höhere Isolation bedeutet weniger Anomalien, aber mehr Sperren/Konflikte und Wiederholungen. Dieser Baum hilft dir, zwischen Read Committed, Repeatable Read/Snapshot und Serializable zu wählen, je nachdem, welche Leseanomalien (Dirty, Non-repeatable, Phantom) du tolerieren kannst.
Kannst du Dirty Reads tolerieren?
Beginne mit der grundlegendsten Anomalie: Soll eine Transaktion Daten lesen können, die noch nicht committet sind (und zurückgerollt werden könnten)? Fast keine ernsthafte Anwendung will das; in den meisten modernen Engines verhindert der Standard Dirty Reads bereits. Gelockert wird das nur für ungefähre/analytische Grobzählungen und maximale Geschwindigkeit.
- Nein, ich darf nur committete Daten lesen
- Ja, ein grobes/ungefähres Lesen reicht (selten)
Musst du beim erneuten Lesen innerhalb derselben Transaktion dasselbe Ergebnis sehen?
Nachdem Dirty Reads ausgeschlossen sind, die nächste Frage: Liest du dieselbe Zeile zweimal innerhalb einer Transaktion, ist es für dich ein Problem, einen anderen Wert zu sehen, weil jemand zwischendurch committet hat (Non-repeatable Read), oder dass neue Zeilen auftauchen (Phantom)? Logik, die Konsistenz bei Berichten/Berechnungen erfordert, braucht meist einen konsistenten Snapshot.
- Nein, jede Anweisung darf die neuesten committeten Daten sehen
- Ja, für die gesamte Transaktion ist ein konsistenter Snapshot nötig
Müssen parallele Transaktionen logisch vollständig geordnet sein?
Du willst konsistente Lesevorgänge; reicht das, oder müssen parallele Transaktionen ein Ergebnis liefern, als wären sie nacheinander gelaufen (Serializable)? Kannst du subtile Anomalien wie Write Skew tolerieren (z. B. zwei Transaktionen, die verschiedene Zeilen lesen und so schreiben, dass sie sich gegenseitig ungültig machen), reicht Snapshot; andernfalls ist volle Serialisierung erforderlich.
- Nein, ein konsistenter Snapshot reicht
- Ja, keine Parallelitätsanomalie ist akzeptabel
Empfehlung: Read Uncommitted (nur Sonderfälle)
Die niedrigste Isolation; sie erlaubt Dirty Reads. Sie liest fast ohne Warten auf Sperren, du siehst aber möglicherweise Daten, die zurückgerollt werden können. Für allgemeine Anwendungen nicht empfohlen.
Empfehlung: Read Committed (Standard-OLTP)
Jede Anweisung sieht die zu diesem Zeitpunkt zuletzt committeten Daten; Dirty Reads werden verhindert. Das ist in den meisten Engines der Standard und bietet für typische OLTP-Workloads das beste Gleichgewicht aus Parallelität und Konsistenz.
Empfehlung: Repeatable Read / Snapshot (konsistente Lesevorgänge)
Die Transaktion arbeitet auf einem konsistenten Snapshot, der zu ihrem Beginn (oder beim ersten Lesen) festgelegt wird; Lesevorgänge ändern sich während der Transaktion nicht. Mit MVCC blockieren Leser keine Schreiber und Schreiber keine Leser.
Empfehlung: Serializable (volle Isolation)
Die höchste Isolation: Parallele Transaktionen liefern ein Ergebnis, als wären sie seriell (nacheinander) ausgeführt worden. Sie verhindert alle Leseanomalien und Write Skew; der Preis sind mehr Konflikte und die Notwendigkeit von Wiederholungen.