Was Sie über die Transaktionsisolierung von msyql wissen müssen

Was ist eine Transaktion?

Eine Transaktion ist eine logische Einheit im Ausführungsprozess eines Datenbankverwaltungssystems, die aus einer endlichen Folge von Datenbankoperationen besteht. Eine Datenbanktransaktion besteht normalerweise aus einer Folge von Lese-/Schreibvorgängen in der Datenbank. Es verfolgt folgende zwei Ziele:

1. Es bietet eine Methode, mit der die Datenbankbetriebssequenz nach einem Fehler in den Normalzustand zurückversetzt werden kann, und stellt außerdem eine Methode bereit, mit der die Datenbank auch in einem abnormalen Zustand ihre Konsistenz beibehalten kann.
2. Wenn mehrere Anwendungen gleichzeitig auf die Datenbank zugreifen, kann eine Isolationsmethode zwischen diesen Anwendungen bereitgestellt werden, um zu verhindern, dass sich ihre Vorgänge gegenseitig stören.

Isolierung und Isolierungsebenen

Wenn es um Transaktionen geht, denken Sie bestimmt an ACID (Atomicity, Consistency, Isolation, Durability). Heute sprechen wir über das I, das für „Isolation“ steht. Wenn mehrere Transaktionen gleichzeitig in einer Datenbank ausgeführt werden, können Dirty Reads, nicht wiederholbare Reads und Phantom Reads auftreten. Um diese Probleme zu lösen, wurde das Konzept der „Isolationsebene“ eingeführt. Je stärker die Isolationsstufe, desto schlechter die Leistung. Daher muss ein Gleichgewicht zwischen Leistung und Isolationsstufe gefunden werden. Zu den SQL-Standardtransaktionsisolationsebenen gehören:

• Nicht festgeschriebenes Lesen: Nachdem eine Transaktion festgeschrieben wurde, sind die von ihr vorgenommenen Änderungen für andere Transaktionen sichtbar. Es wird ein Dirty Read auftreten.
• Festgeschriebenes Lesen: Nachdem eine Transaktion festgeschrieben wurde, sind die von ihr vorgenommenen Änderungen für andere Transaktionen sichtbar. Dies führt zu nicht wiederholbaren Lesevorgängen.
• Wiederholbares Lesen: Die während der Ausführung einer Transaktion angezeigten Daten stimmen immer mit den Daten überein, die beim Start der Transaktion angezeigt wurden. Natürlich sind auf der Isolationsebene für wiederholbares Lesen nicht festgeschriebene Änderungen auch für andere Transaktionen unsichtbar. Es kommt zu Phantom-Lesevorgängen.
• Serialisierbar: Wie der Name schon sagt, fügt „Schreiben“ für dieselbe Datensatzzeile eine „Schreibsperre“ und „Lesen“ eine „Lesesperre“ hinzu. Wenn ein Lese-/Schreibsperrenkonflikt auftritt, muss die später aufgerufene Transaktion warten, bis die vorherige Transaktion abgeschlossen ist, bevor sie mit der Ausführung fortfahren kann.

Der Hauptgrund besteht darin, dass es schwierig ist, zwischen festgeschriebenem und wiederholbarem Lesen zu unterscheiden. Sehen wir uns daher ein kleines Beispiel an. Erstellen Sie zunächst eine Tabelle und fügen Sie Daten ein 1

Datenbanktest erstellen;
Test verwenden;
Tabelle erstellen Test (ID int Primärschlüssel);
in Test(ID) Werte(1) einfügen;

Schauen wir uns die unterschiedlichen Rückgabeergebnisse von Transaktion A unter unterschiedlichen Isolationsstufen an, nämlich die Rückgabewerte von V1, V2 und V3 in der Abbildung.

• Wenn die Isolationsebene auf „Read Uncommitted“ (nicht festgeschrieben) eingestellt ist, beträgt der Wert von V1 2. Obwohl Transaktion B zu diesem Zeitpunkt noch nicht festgeschrieben wurde, hat A das Ergebnis gesehen. Daher sind V2 und V3 auch 2.
• Wenn die Isolationsebene „Read Committed“ ist, ist V1 1 und V2 2. Die Aktualisierungen der Transaktion B können von A erst gesehen werden, nachdem sie festgeschrieben wurden. Daher ist der Wert von V3 ebenfalls 2.
• Wenn die Isolationsebene „wiederholbares Lesen“ ist, sind V1 und V2 1 und V3 ist 2. Der Grund, warum V2 immer noch 1 ist, besteht darin, dass es dieser Anforderung folgt: Die von der Transaktion während der Ausführung gesehenen Daten müssen vorher und nachher konsistent sein.
• Wenn die Isolationsebene „serialisierbar“ ist, wird Transaktion B gesperrt, wenn sie „1 in 2 ändern“ ausführt. Die Ausführung von Transaktion B kann erst fortgesetzt werden, nachdem Transaktion A festgeschrieben wurde. Aus Sicht von A sind die Werte von V1 und V2 also 1 und der Wert von V3 ist 2.

In der Datenbank wird eine Ansicht erstellt und das logische Ergebnis der Ansicht wird beim Zugriff darauf verwendet. Unter der Isolationsebene „wiederholbares Lesen“ wird diese Ansicht beim Start der Transaktion erstellt und während der gesamten Transaktion verwendet. In der Isolationsebene „Read Committed“ wird diese Ansicht zu Beginn jeder SQL-Anweisungsausführung erstellt. Hierbei ist zu beachten, dass die Isolationsebene „Read Uncommitted“ den aktuellsten Wert im Datensatz direkt und ohne das Konzept einer Ansicht zurückgibt, während die Isolationsebene „serialisierbar“ Sperren direkt verwendet, um parallele Zugriffe zu vermeiden.

Wann ist also das Szenario des **„wiederholbaren Lesens“** erforderlich?

Angenommen, Sie verwalten eine Tabelle mit persönlichen Bankkonten. In einer Tabelle wird der Saldo am Ende jedes Monats gespeichert, in der anderen Tabelle die Rechnungsdetails. Zu diesem Zeitpunkt müssen Sie eine Datenkorrektur durchführen, das heißt, feststellen, ob die Differenz zwischen dem Saldo des Vormonats und dem aktuellen Saldo mit den Rechnungsdetails dieses Monats übereinstimmt. Sie müssen hoffen, dass selbst wenn ein Benutzer während des Korrekturlesevorgangs eine neue Transaktion durchführt, Ihre Korrekturleseergebnisse dadurch nicht beeinträchtigt werden.

Implementierung der Transaktionsisolation

In MySQL wird tatsächlich für jeden Datensatz ein Rollback-Vorgang aufgezeichnet, wenn dieser aktualisiert wird. Der neueste Wert im Datensatz kann verwendet werden, um durch einen Rollback-Vorgang den Wert des vorherigen Status abzurufen. Angenommen, ein Wert wird nacheinander von 1 in 2, 3 und 4 geändert. In diesem Fall entsteht im Rollback-Protokoll ein Eintrag ähnlich dem folgenden.

Der aktuelle Wert ist 4, aber bei der Abfrage dieses Datensatzes haben Transaktionen, die zu unterschiedlichen Zeiten gestartet wurden, unterschiedliche Leseansichten. Wie in der Abbildung gezeigt, lauten die Werte dieses Datensatzes in den Ansichten A, B und C jeweils 1, 2 und 4. Derselbe Datensatz kann im System mehrere Versionen haben, was der Multi-Version Concurrency Control (MVCC) der Datenbank entspricht. Um für die Lese-Ansicht A 1 zu erhalten, müssen Sie alle Rollback-Operationen in der Abbildung nacheinander ausführen, um den aktuellen Wert zu erhalten. Selbst wenn es eine andere Transaktion gibt, die 4 in 5 ändert, gerät diese Transaktion nicht mit den Transaktionen in Konflikt, die den Lese-Ansichten A, B und C entsprechen.

Das Rollback-Protokoll kann nicht ewig aufbewahrt werden. Wann sollte es gelöscht werden?

Löschen Sie es, wenn es nicht benötigt wird. Mit anderen Worten: Das System bestimmt, dass die Rollback-Protokolle gelöscht werden, wenn keine Transaktion mehr diese Rollback-Protokolle benötigt.

Ab wann ist es nicht mehr nötig?

Dies ist der Fall, wenn im System keine Lese-Ansicht vorhanden ist, die vor diesem Rollback-Protokoll liegt.

Warum sollten Sie die Verwendung von Transaktionen vermeiden?

Transaktionen bedeuten, dass im System sehr alte Transaktionsansichten vorhanden sind. Bevor die Transaktion festgeschrieben wird, müssen die Rollback-Datensätze beibehalten werden, wodurch viel Speicherplatz belegt wird. Darüber hinaus belegen Transaktionen Sperrressourcen und können zum Absturz der Datenbank führen.

Oben finden Sie die Details, die Sie über die Transaktionsisolierung von MySQL wissen müssen. Weitere Informationen zur Transaktionsisolierung von MySQL finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!