Beschreiben Sie kurz die vier Transaktionsisolationsebenen von MySql

Isolationsstufe:

Isolation ist komplizierter als Sie vielleicht denken. Der SQL-Standard definiert vier Isolationsebenen, die bestimmen, welche in jeder Transaktion vorgenommenen Änderungen innerhalb und zwischen Transaktionen sichtbar und welche unsichtbar sind. Niedrigere Isolationsgrade ermöglichen im Allgemeinen eine höhere Parallelität und einen geringeren System-Overhead.

Nachfolgend finden Sie eine kurze Einführung in die vier Isolationsebenen.

1.READ UNCOMMITTED (nicht festgeschriebenes Lesen)

Auf der Ebene READ UNCOMMITTED sind in einer Transaktion vorgenommene Änderungen, auch wenn sie nicht festgeschrieben sind, für andere Transaktionen sichtbar. Transaktionen können nicht festgeschriebene Daten lesen, was auch als Dirty Read bezeichnet wird. Diese Ebene kann viele Probleme verursachen. In Bezug auf die Leistung ist READ UNCOMMITTED nicht viel besser als andere Ebenen, aber es fehlen viele der Vorteile anderer Ebenen. Sofern es keinen sehr zwingenden Grund gibt, wird es in tatsächlichen Anwendungen selten verwendet.

(1) Alle Transaktionen können die Ausführungsergebnisse anderer nicht festgeschriebener Transaktionen sehen

(2) Diese Isolationsebene wird in tatsächlichen Anwendungen selten verwendet, da ihre Leistung nicht viel besser ist als bei anderen Ebenen.

(3) Das durch diese Ebene verursachte Problem ist Dirty Read: Nicht festgeschriebene Daten werden gelesen

#Ändern Sie zuerst die Isolationsebene: tx_isolation='READ-UNCOMMITTED';
wählen Sie @@tx_isolation;
+------------------+
| @@tx_isolation |
+------------------+
| LESEN-UNCOMMITTED |
+------------------+#Transaktion A: Starten Sie eine Transaktion, starten Sie die Transaktion.
wähle * aus tx;
+------+------+
| ID | Nummer |
+------+------+
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
+------+------+#Transaktion B: starte auch eine Transaktion (dann kreuzen sich die beiden Transaktionen)
Führen Sie die Aktualisierungsanweisung in Transaktion B aus, ohne die Starttransaktion festzuschreiben.
Aktualisiere TX-Set Num=10, wobei ID=1 ist;
wähle * aus tx;
+------+------+
| ID | Nummer |
+------+------+
| 1 | 10 |
| 2 | 2 |
| 3 | 3 |
+------+------+#Transaktion A: Kann Transaktion A die aktualisierten Daten zu diesem Zeitpunkt sehen?
wähle * aus tx;
+------+------+
| ID | Nummer |
+------+------+
| 1 | 10 | ---> Das sieht man! Das bedeutet, wir haben Daten gelesen, die von Transaktion B noch nicht festgeschrieben wurden. | 2 | 2 |
| 3 | 3 |
+------+------+#Transaktion B: Transaktion B wird zurückgesetzt, aber das Rollback ist noch nicht festgeschrieben;
wähle * aus tx;
+------+------+
| ID | Nummer |
+------+------+
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
+------+------+#Transaktion A: Die in Transaktion A angezeigten Daten sind auch die Daten, die B nicht übermittelt hat. select * from tx;
+------+------+
| ID | Nummer |
+------+------+
| 1 | 1 | ---> Dirty Read bedeutet, dass ich mich in dieser Transaktion (A) befinde, obwohl Transaktion B noch nicht committet wurde, aber dennoch keinerlei Datenänderungen darin sehe!
| 2 | 2 |
| 3 | 3 |
+------+------+

2.READ COMMITTED (gelesenes Commitment)

Die Standardisolationsebene der meisten Datenbanksysteme ist READ COMMITTED, bei MySQL jedoch nicht. READ COMMITTED erfüllt die oben genannte einfache Definition von Isolation: Wenn eine Transaktion gestartet wird, kann sie nur die Änderungen „sehen“, die von Transaktionen vorgenommen wurden, die festgeschrieben wurden. Mit anderen Worten: Alle von einer Transaktion vom Beginn bis zu ihrer Festschreibung vorgenommenen Änderungen sind für andere Transaktionen nicht sichtbar. Diese Ebene wird manchmal als nicht wiederholbares Lesen bezeichnet, da die zweimalige Ausführung derselben Abfrage zu unterschiedlichen Ergebnissen führen kann.

(1) Dies ist die Standardisolationsebene für die meisten Datenbanksysteme (aber nicht für MySQL).

(2) Es genügt der einfachen Definition der Isolation: Eine Transaktion kann nur Änderungen sehen, die von bereits festgeschriebenen Transaktionen vorgenommen wurden.

(3) Das Problem mit dieser Isolationsebene ist das nicht wiederholbare Lesen: Nicht wiederholbares Lesen bedeutet, dass wir möglicherweise unterschiedliche Ergebnisse sehen, wenn wir genau dieselbe Select-Anweisung in derselben Transaktion ausführen.

Mögliche Ursachen hierfür:

(1) Es findet eine übergreifende Transaktion mit einem neuen Commit statt, die eine Änderung der Daten zur Folge hat.

(2) Wenn eine Datenbank von mehreren Instanzen betrieben wird, kann es während der Verarbeitung dieser Instanz bei anderen Instanzen derselben Transaktion zu neuen Commits kommen.

#Ändern Sie zuerst die Isolationsebene tx_isolation='read-committed';
wählen Sie @@tx_isolation;
+----------------+
| @@tx_isolation |
+----------------+
| GELESEN-ENGAGIERT |
+----------------+#Transaktion A: Starten Sie eine Transaktion, starten Sie die Transaktion.
wähle * aus tx;
+------+------+
| ID | Nummer |
+------+------+
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
+------+------+#Transaktion B: starte auch eine Transaktion (dann kreuzen sich die beiden Transaktionen)
In dieser Transaktion werden die Daten aktualisiert und die Starttransaktion wird nicht festgeschrieben.
Aktualisiere TX-Set Num=10, wobei ID=1 ist;
wähle * aus tx;
+------+------+
| ID | Nummer |
+------+------+
| 1 | 10 |
| 2 | 2 |
| 3 | 3 |
+------+------+#Transaktion A: Können wir die Datenänderungen in Transaktion A zu diesem Zeitpunkt sehen?
wähle * aus tx; --------------->
+------+------+ |
| ID | Nummer | |
+------+------+ |
| 1 | 1 |--->Kann es nicht sehen! |
| 2 | 2 | |
| 3 | 3 | |
+------+------+ |——>Dieselbe Select-Anweisung, aber unterschiedliche Ergebnisse|
#Transaktion B: Was passiert, wenn Transaktion B festgeschrieben wird? |
verpflichten; |
|
#Transaktion A: |
wähle * aus tx; --------------->
+------+------+
| ID | Nummer |
+------+------+
| 1 | 10 |--->Da Transaktion B festgeschrieben wurde, können wir die Datenänderungen in A | 2 | 2 | sehen.
| 3 | 3 |
+------+------+

3. WIEDERHOLBARES LESEN

REPEATABLE READ löst das Dirty-Read-Problem. Diese Ebene stellt sicher, dass die Ergebnisse des mehrmaligen Lesens desselben Datensatzes in derselben Transaktion konsistent sind. Theoretisch kann die Isolationsebene „Repeatable Read“ jedoch ein weiteres Problem nicht lösen: „Phantom Read“. Das sogenannte Phantomlesen bezieht sich auf die Situation, in der eine Transaktion Datensätze in einem bestimmten Bereich liest und eine andere Transaktion neue Datensätze in den Bereich einfügt. Wenn die vorherige Transaktion die Datensätze im Bereich erneut liest, werden Phantomzeilen generiert. Die Speicher-Engines InnoDB und XtraDB lösen das Problem des Phantomlesens durch Multiversion Concurrency Control (MVCC, Multiversion Concurrency Control).

(1) Dies ist die Standard-Transaktionsisolationsebene von MySQL

(2) Es stellt sicher, dass mehrere Instanzen derselben Transaktion beim gleichzeitigen Lesen von Daten dieselben Zeilen sehen.

(3) Probleme, die auf dieser Ebene auftreten können - Phantom Read: Wenn ein Benutzer einen Bereich von Datenzeilen liest, fügt eine andere Transaktion neue Zeilen in den Bereich ein. Wenn der Benutzer die Datenzeilen im Bereich erneut liest, werden neue Phantomzeilen gefunden.

(4) Die Speicher-Engines InnoDB und Falcon lösen dieses Problem durch den Multiversion Concurrency Control (MVCC)-Mechanismus

#Ändern Sie zuerst die Isolationsebene: tx_isolation='repeatable-read';
wählen Sie @@tx_isolation;
+-----------------+
| @@tx_isolation |
+-----------------+
| WIEDERHOLBARES LESEN |
+-----------------+#Transaktion A: Starten Sie eine Transaktion, starten Sie die Transaktion.
wähle * aus tx;
+------+------+
| ID | Nummer |
+------+------+
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
+------+------+#Transaktion B: Starten Sie eine neue Transaktion (dann kreuzen sich die beiden Transaktionen)
Aktualisieren Sie die Daten in der Transaktion B und führen Sie einen Commit für den Start der Transaktion aus.
Aktualisiere TX-Set Num=10, wobei ID=1 ist;
wähle * aus tx;
+------+------+
| ID | Nummer |
+------+------+
| 1 | 10 |
| 2 | 2 |
| 3 | 3 |
+------+------+
commit;#Transaktion A: Kann A die Datenänderungen sehen, auch wenn Transaktion B festgeschrieben wurde?
wähle * aus tx;
+------+------+
| ID | Nummer |
+------+------+
| 1 | 1 | ---> Kann es immer noch nicht sehen! (Dies unterscheidet sich von Level 2, was auch zeigt, dass Level 3 das Problem des nicht wiederholbaren Lesens löst.)
| 2 | 2 |
| 3 | 3 |
+------+------+#Transaktion A: Nur wenn Transaktion A auch festgeschrieben ist, kann sie das Festschreiben der Datenänderungen sehen.
wähle * aus tx;
+------+------+
| ID | Nummer |
+------+------+
| 1 | 10 |
| 2 | 2 |
| 3 | 3 |
+------+------+

4.SERIALISIERBAR

SERIALIZABLE ist die höchste Isolationsebene. Es vermeidet das oben erwähnte Phantomleseproblem, indem es die serielle Ausführung von Transaktionen erzwingt. Kurz gesagt, SERIALIZABLE sperrt jede gelesene Datenzeile, sodass es zu vielen Timeouts und Sperrkonflikten kommen kann. Diese Isolationsebene wird in tatsächlichen Anwendungen selten verwendet. Sie wird nur dann in Betracht gezogen, wenn die Gewährleistung der Datenkonsistenz unbedingt erforderlich ist und keine Parallelität akzeptabel ist.

(1) Dies ist die höchste Isolationsstufe

(2) Es löst das Phantom-Read-Problem, indem es eine Reihenfolge der Transaktionen erzwingt, in der sie nicht miteinander in Konflikt geraten können. Kurz gesagt: Es wird für jede gelesene Datenzeile eine gemeinsame Sperre hinzugefügt.

(3) Auf dieser Ebene kann es zu zahlreichen Timeouts und Sperrkonflikten kommen.

#Ändern Sie zuerst den Isolationslevel-Satz tx_isolation='serializable';
wählen Sie @@tx_isolation;
+----------------+
| @@tx_isolation |
+----------------+
| SERIALISIERBAR |
+----------------+#Transaktion A: Starten Sie eine neue Transaktion, starten Sie die Transaktion;#Transaktion B: Bevor A festgeschrieben ist, kann diese übergreifende Transaktion die Daten der Starttransaktion nicht ändern.
TX-Werte einfügen('4','4');
FEHLER 1205 (HY000): Wartezeit für Sperre überschritten; versuchen Sie, die Transaktion neu zu starten.
Aktualisiere TX-Set Num=10, wobei ID=1 ist;
FEHLER 1205 (HY000): Wartezeit für Sperre überschritten; versuchen Sie, die Transaktion neu zu starten.

Oben finden Sie eine kurze Beschreibung der Details der vier Isolationsebenen von MySql. Weitere Informationen zu MySQL-Isolationsebenen finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!