Detaillierte Erläuterung des Implementierungsprinzips von MySQL-Transaktionen und Spring-Isolationsebenen

1. Transaktionen haben ACID-Eigenschaften

• Atomarität: Eine Transaktion ist die kleinste Arbeitseinheit, die nicht durch eine Transaktion geteilt werden kann. Entweder wird die gesamte Transaktion festgeschrieben, oder sie schlägt fehl und wird zurückgesetzt.
• Konsistenz: Die Datenbank wechselt immer von einem konsistenten Zustand in einen anderen konsistenten Zustand, der nur die Ergebnisse erfolgreicher Transaktions-Commits enthält.
• Isolation: Die durch eine Transaktion vorgenommenen Änderungen werden am Ende gemeinsam übermittelt und sind für andere Transaktionen nicht sichtbar.
• Dauerhaftigkeit: Sobald eine Transaktion bestätigt wurde, werden die dadurch vorgenommenen Änderungen dauerhaft in der Datenbank gespeichert.
  

2. Transaktionsisolationsebene

1) Definition und Probleme der Isolationsstufe

• LESEN UNCOMMITTED: Von einer Transaktion vorgenommene Änderungen sind für andere Transaktionen sichtbar, auch wenn sie nicht committet wurden. Transaktionen können nicht festgeschriebene Daten lesen, eine Situation, die als „Dirty Read“ bezeichnet wird.
• READ COMMITTED: Transaktionen lesen festgeschriebene Daten. Dies ist die Standardisolationsebene für die meisten Datenbanken. Wenn eine Transaktion ausgeführt wird, werden die Daten durch eine andere Transaktion geändert, wodurch die vor und nach dieser Transaktion gelesenen Informationen unterschiedlich sind. Diese Situation wird als nicht wiederholbares Lesen bezeichnet.
• PEPEATABLE READ (wiederholbares Lesen): Diese Ebene ist die Standardisolationsebene von MySQL. Sie löst das Problem des Dirty Read und stellt sicher, dass mehrere Lesevorgänge desselben Datensatzes durch dieselbe Transaktion konsistent sind. Allerdings können auf dieser Ebene immer noch Phantom-Lesevorgänge auftreten. Phantomlesen bedeutet, dass, wenn eine Transaktion A einen Datenbereich liest, eine andere Transaktion B Zeilen in diesen Bereich einfügt. Wenn Transaktion A die Daten in diesem Bereich erneut liest, werden Phantomzeilen generiert. Besonderer Hinweis: Die Speicher-Engines InnoDB und XtraDB lösen das Phantomleseproblem durch Multiversion Concurrency Control (MVCC). Dabei werden Lückensperren (Next-Key-Locking) verwendet, um die Lücken in den an der Abfrage beteiligten Zeilen und Indizes zu sperren und so das Einfügen von Phantomzeilen zu verhindern.
• SERIALIZABLE: Diese Transaktion stellt die höchste Isolationsebene dar, die eine serielle Ausführung von Transaktionen erzwingt und so Phantomleseprobleme vermeidet. Kurz gesagt: SERIALIZABLE sperrt jede gelesene Datenzeile, sodass es zu zahlreichen Timeouts und Sperrkonflikten kommen kann.

2) Wenn Sie die Änderungs- und Isolationsstufe von MySQL anzeigen

Variablen wie „tx_isolation“ anzeigen; # Isolationsebene vor MySQL8 anzeigen Variablen wie „transaction_isolation“ anzeigen; # Isolationsebene vor MySQL8 anzeigen

setze global transaction_isolation='READ-COMMITTED'; // Setze die Isolationsebene, Ventildomäne READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE

Die Transaktionsisolationsebene kann auf Sitzungsebene liegen. Wir können für verschiedene Sitzungen unterschiedliche Ebenen festlegen:

Legen Sie die Isolationsebene für Sitzungstransaktionen fest und lesen Sie nicht fest.
Isolationsstufe für Sitzungstransaktionen festlegen, Lesen festgeschrieben;
Legen Sie die Isolationsstufe für Sitzungstransaktionen fest und erlauben Sie ein wiederholbares Lesen.
Legen Sie die serialisierbare Isolationsebene für Sitzungstransaktionen fest.

3) Isolationsstufe für Spring-Transaktionen

Spring-Transaktionen verwenden standardmäßig die Datenbankisolationsstufe. Sie können die Sitzungsisolationsstufe anpassen, indem Sie den Isolationsparameter in @Transactional kommentieren. Die Isolationsebene befindet sich auf Sitzungsebene und die JDBC-Schnittstelle java.sql.Connection unterstützt das Festlegen der Isolationsebene.

Wenn Spring eine Transaktion startet (DataSourceTransactionManager.doBegin), legt es die Isolationsstufe der Verbindung entsprechend der Annotation-Konfiguration fest:

Der MySQL-Treiber com.mysql.cj.jdbc.ConnectionImpl führt SQL-Anweisungen aus, um die Isolationsstufe auf Sitzungsebene anzupassen

3. Sackgasse

Ein Deadlock tritt auf, wenn zwei oder mehr Transaktionen dieselbe Ressource belegen und die Sperrung der von den anderen Transaktionen belegten Ressourcen anfordern, wodurch ein Teufelskreis entsteht. Deadlock-Beispiel:

# Transaktion 1 Transaktion starten;
Konto aktualisieren, Geld festlegen=10, wobei ID=1;
Konto aktualisieren, Geld festlegen=20, wobei ID=2;
begehen;

# Transaktion 2, Transaktion starten;
Konto aktualisieren, Geld festlegen=10, wobei ID=2;
Konto aktualisieren, Geld festlegen=20, wobei ID=1;
begehen;

Angenommen, Transaktion 1 und Transaktion 2 führen zufällig gleichzeitig die erste Aktualisierungsanweisung aus und bereiten sich dann auf die Ausführung der zweiten Aktualisierungsanweisung vor, stellen jedoch fest, dass der Datensatz von der anderen Partei gesperrt wurde. Dann warten die beiden Transaktionen darauf, dass die andere Partei Ressourcen freigibt, während sie die von der anderen Partei benötigte Sperre aufrechterhalten, was zu einer Endlosschleife führt.

Um Deadlock-Probleme zu vermeiden, implementiert die Datenbank verschiedene Mechanismen zur Deadlock-Erkennung und zur Vermeidung von Deadlock-Überlängen. InnoDB behandelt Deadlocks, indem es die Transaktion zurücksetzt, die die kürzeste exklusive Sperre auf Zeilenebene enthält.

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.