Transaktionsisolationsebenen

Die Transaktionsisolationsebene wird als ein Zustand innerhalb von Datenbanken verstanden, der die Menge an Daten angibt, die für eine Anweisung in einer Transaktion sichtbar ist, insbesondere wenn dieselben Daten von vielen Transaktionen gleichzeitig zugegriffen werden. Stellen wir uns eine Situation vor, in der wir eine Tabelle “Customers” mit 1 Million Zeilen haben, die 10 GB Speicherplatz belegt. Um 9 Uhr haben wir eine Abfrage “SELECT * FROM Customers” gestartet, die alle Zeilen der Tabelle abfragt. In unserem Fall dauert diese Abfrage ungefähr 5 Minuten, um abgeschlossen zu werden. Diese Zeit wird benötigt, um unsere Tabelle vollständig zu scannen und die Zeilen abzurufen. Diese Art der 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 Tabelle “Customers” 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 begonnen hatte.

Das Ergebnis unserer Abfrage hängt vom Isolationsgrad der Transaktion ab. Im Wesentlichen gibt es 4 unten erläuterte Isolationsebenen:

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 konsistent mit anderen Teilen der Tabelle oder der Abfrage sind und möglicherweise noch nicht bestätigt wurden. „Dirty Reads“ gewährleistet die schnellste Leistung, da Daten ohne Validierung direkt aus den Tabellenblöcken gelesen werden.
2. Read committed. Wir werden die von UserB durchgeführten Änderungen nicht sehen. Dies geschieht, weil in dieser Isolationsebene die von einer Abfrage abgerufenen Zeilen die Zeilen sind, die vor dem Start der Abfrage bestätigt wurden. Das bedeutet, dass die von UserB vorgenommenen Änderungen nicht vorhanden waren, als die Abfrage gestartet wurde, sodass die Änderungen nicht in das Abfrageergebnis einbezogen werden.
3. Repeatable read. Wir werden die Änderungen von UserB nicht sehen. Dies geschieht aufgrund der Tatsache, dass bei der Isolationsstufe “Repeatable Read” die von einer Abfrage abgerufenen Zeilen die Zeilen sind, die zum Zeitpunkt des Beginns der Transaktion bestätigt wurden. Das bedeutet, dass die von UserB vorgenommenen Änderungen nicht vorhanden waren, als die Transaktion begann, und daher nicht in das Abfrageergebnis einbezogen werden. „Alle konsistenten Lesevorgänge innerhalb derselben Transaktion lesen den Schnappschuss, der durch den ersten Lesevorgang erstellt wurde“ (aus der MySQL-Dokumentation).
4. Serializable. Diese Isolationsstufe bedeutet, dass alle Datenbanktransaktionen in völlig isolierter Weise stattfinden. In dieser Isolationsebene werden alle Transaktionen seriell, eine nach der anderen, ausgeführt. Das DBMS kann zwei oder mehr Transaktionen gleichzeitig ausführen, nur wenn der Anschein einer seriellen Ausführung aufrechterhalten werden kann. In der Praxis ist Serializable den Repeatable Reads sehr ähnlich, verwendet jedoch eine andere Implementierungstechnik für jede Datenbank-Engine. Zum Beispiel wird in Oracle die Isolationsstufe “Repeatable Read” nicht unterstützt, und “Serializable” bietet die höchste Isolationsstufe. Diese Isolationsstufe ähnelt “Repeatable Read”, jedoch konvertiert InnoDB implizit alle einfachen SELECT-Anweisungen in “SELECT … LOCK IN SHARE MODE”.