Detaillierte Erläuterung der Transaktionsisolierungsebenen der MySQL-Datenbank

Isolationsebene für Datenbanktransaktionen

Es gibt 4 Isolationsstufen für Datenbanktransaktionen, von niedrig bis hoch:

1. Nicht festgeschriebenes Lesen: Dirty Reads sind zulässig.
2. Read Committed: Verhindert Dirty Reads. Dies ist die am häufigsten verwendete Isolationsebene und die Standardisolationsebene für die meisten Datenbanken.
3. Wiederholbares Lesen: Es kann Dirty Read und nicht wiederholbares Lesen verhindern.
4. Serialisierbar: Es kann Dirty Reads, nicht wiederholbare Reads und Phantom Reads verhindern und (die Transaktionsserialisierung) verringert die Effizienz der Datenbank.
   

Diese vier Ebenen können die Probleme „Dirty Read“, „Non-Repeatable Read“ und „Phantom Read“ nacheinander lösen.

√: Kann erscheinen ×: Wird nicht erscheinen

Hinweis: Wir diskutieren das Szenario der Isolationsebene hauptsächlich, wenn mehrere Transaktionen gleichzeitig ausgeführt werden.

Dirty Reads, Phantom Reads und nicht wiederholbare Reads

Schmutzige Lektüre:

Dirty Read bedeutet, dass, wenn eine Transaktion auf Daten zugreift und diese ändert, und diese Änderung nicht an die Datenbank übermittelt wurde, eine andere Transaktion ebenfalls auf die Daten zugreift und die Daten verwendet.

Nicht wiederholbares Lesen:

Dabei werden dieselben Daten innerhalb einer Transaktion mehrmals gelesen. Bevor diese Transaktion beendet wird, greift eine weitere Transaktion auf dieselben Daten zu. Daher können die von der ersten Transaktion zweimal gelesenen Daten zwischen den beiden Lesevorgängen in der ersten Transaktion aufgrund der Änderung der zweiten Transaktion unterschiedlich sein. Dies bedeutet, dass die in einer Transaktion zweimal gelesenen Daten unterschiedlich sind; deshalb spricht man vom nicht wiederholbaren Lesen. (Das heißt, derselbe Dateninhalt kann nicht gelesen werden)

Phantomlesung:

Es bezeichnet ein Phänomen, das auftritt, wenn Transaktionen nicht unabhängig voneinander ausgeführt werden. Beispielsweise ändert die erste Transaktion die Daten in einer Tabelle, und diese Änderung betrifft alle Datenzeilen in der Tabelle. Gleichzeitig ändert die zweite Transaktion auch die Daten in dieser Tabelle, indem sie eine neue Datenzeile in die Tabelle einfügt. Dann kann es passieren, dass der Benutzer bei der ersten Transaktion wie bei einer Halluzination feststellt, dass in der Tabelle immer noch unveränderte Datenzeilen vorhanden sind.

Beispiel:

Oberfläche:

Tabelle erstellen `cc_wsyw126_user_test_isolation_copy` (
 `id` int(11) NICHT NULL AUTO_INCREMENT,
 `Passwort` varchar(64) NOT NULL,
 `Alter` int(11) NICHT NULL,
 Primärschlüssel (`id`),
 SCHLÜSSEL `ix_age` (`Alter`)
)ENGINE=MyISAM STANDARD-CHARSET=utf8;

Simulierte Daten:

INSERT INTO `cc_wsyw126_user_test_isolation_copy` (`Passwort`, `Alter`) 
WERTE 
('1', 1),
('zweiundzwanzig),
('3', 3),
('4', 4);

Die erste Transaktion A:

Transaktion starten 
in cc_wsyw126_user_test_isolation_copy (Passwort, Alter) Werte einfügen ('5',5)
begehen

Die zweite Transaktion B:

Transaktion starten 
Aktualisiere cc_wsyw126_user_test_isolation_copy und setze Alter = 2, wobei Passwort >='2' ist.
Wählen Sie * aus cc_wsyw126_user_test_isolation_copy, wobei Kennwort >= „2“ ist.
begehen

Schritte zum Reproduzieren:

Solange die Insert-Anweisung der Transaktion A vor der Select-Anweisung und nach der Update-Anweisung der Transaktion B steht, ist alles in Ordnung.

Die MySQL InnoDB-Speicher-Engine implementiert ein Multi-Version Concurrency Control-Protokoll – MVCC (Multi-Version Concurrency Control) sowie eine Next-Key-Locking-Strategie, um Phantom-Lesevorgänge auf der Isolationsebene Repeatable Read (RR) zu verhindern. Wenn Sie Phantom-Lesevorgänge testen möchten, experimentieren Sie mit MyISAM.

Wenn in einem gruppierten Index (Primärschlüsselindex) eine eindeutige Einschränkung vorliegt, stuft InnoDB die standardmäßige Next-Key-Sperre auf eine Datensatzsperre herab.

Vielen Dank fürs Lesen, ich hoffe, es kann Ihnen helfen, danke für Ihre Unterstützung dieser Site!