Transaktionsisolationsebenen

Das Transaktionsisolationsebene wird als ein Zustand innerhalb von Datenbanken verstanden, der die Menge der Daten festlegt, die für eine Anweisung innerhalb einer Transaktion sichtbar sind, insbesondere wenn dieselben Daten von vielen Transaktionen gleichzeitig zugegriffen werden. Stellen wir uns eine Situation vor, in der wir eine Customer-Tabelle mit 1 Million Zeilen haben, die 10 GB Speicherplatz auf der Festplatte einnimmt. Um 9 Uhr starteten wir eine Abfrage “SELECT * FROM Customers”, die alle Zeilen der Tabelle abfragt. In unserem Fall dauert diese Abfrage etwa 5 Minuten, um abgeschlossen zu werden. Diese Zeit wird benötigt, um unsere Tabelle vollständig zu scannen und die Zeilen abzurufen. Diese Art von Abfrage führt einen vollständigen Tabellenscan durch und kann aus Leistungssicht nicht empfohlen werden. Um 9:01 Uhr aktualisiert UserB die letzte Zeile in der Customer-Tabelle und bestätigt die Änderung. Kurz darauf erreicht unsere Abfrage die letzte von UserB geänderte Zeile. Was wird also passieren? Werden wir den ursprünglichen Zeilenwert oder den geänderten Zeilenwert sehen? Der neue Zeilenwert ist legitim und bestätigt, aber er wurde aktualisiert, nachdem unsere Abfrage gestartet wurde.

Das Ergebnis unserer Abfrage hängt von der Isolationsebene der Transaktion ab. Grundsätzlich gibt es vier Isolationsebenen, die unten erklärt werden:

1. Read uncommitted. Wir werden die von UserB vorgenommenen Änderungen sehen. Diese Isolationsebene wird auch als “dirty reads” bezeichnet, was bedeutet, dass gelesene Daten nicht mit anderen Teilen der Tabelle oder der Abfrage übereinstimmen und möglicherweise noch nicht bestätigt wurden. “Dirty reads” gewährleistet die schnellste Leistung, da Daten direkt aus den Tabellenblöcken ohne Validierung gelesen werden.
2. Read committed. Wir werden die von UserB vorgenommenen Änderungen nicht sehen. Das liegt daran, dass bei dieser Isolationsebene der Abfrage die von einer Abfrage abgerufenen Zeilen die Zeilen sind, die vor dem Start der Abfrage bestätigt wurden. Das bedeutet, dass die Änderungen von UserB nicht vorhanden waren, als die Abfrage gestartet wurde, sodass die Änderungen nicht in die Abfrageergebnisse einbezogen werden.
3. Repeatable read. Wir werden die von UserB vorgenommenen Änderungen nicht sehen. Dies liegt daran, dass bei der Isolationsebene „Repeatable Read“ die von einer Abfrage abgerufenen Zeilen die sind, die zum Zeitpunkt des Starts der Transaktion bestätigt wurden. Das bedeutet, dass die Änderungen von UserB nicht vorhanden waren, als die Transaktion gestartet wurde und daher nicht in die Abfrageergebnisse einbezogen werden. „Alle konsistenten Lesevorgänge innerhalb derselben Transaktion lesen den Snapshot, der beim ersten Lesen erstellt wurde“ (aus der MySQL-Dokumentation)
4. Serializable. Diese Isolationsebene bedeutet, dass alle Datenbanktransaktionen auf völlig isolierte Weise stattfinden. In dieser Isolationsebene werden alle Transaktionen nacheinander ausgeführt. Das DBMS kann zwei oder mehr Transaktionen gleichzeitig ausführen, wenn die Illusion der seriellen Ausführung aufrechterhalten werden kann. In der Praxis ähnelt Serializable sehr stark Repeatable Read, verwendet jedoch für jede Datenbank-Engine eine andere Implementierungstechnik. In Oracle beispielsweise wird die Isolationsebene „Repeatable Read“ nicht unterstützt und „Serializable“ bietet die höchste Isolationsebene. Diese Isolationsebene ähnelt „Repeatable Read“, aber InnoDB konvertiert automatisch alle einfachen SELECT-Anweisungen in „SELECT … LOCK IN SHARE MODE“.