So wählen Sie die Transaktionsisolationsebene in einem MySQL-Projekt

Einführung

Beginnen wir mit unserem Inhalt. Ich glaube, jeder hat das folgende Interview-Szenario schon einmal erlebt.

Interviewer: „Wie viele Transaktionsisolationsebenen hat MySQL?“
Sie: „Nicht festgeschriebenes Lesen, festgeschriebenes Lesen, wiederholbares Lesen, serialisierbar! Die Standardeinstellung ist wiederholbares Lesen.“
Interviewer: „Warum wählt MySQL wiederholbares Lesen als Standardisolationsebene?“
(Sie schauen verbittert und wissen nicht, was Sie antworten sollen!)
Interviewer: „Welche Isolationsstufe haben Sie in Ihrem Projekt gewählt? Warum?“
Sie: „Natürlich ist es der standardmäßige wiederholbare Lesevorgang. Und der Grund … äh …“
(Dann können Sie zurückgehen und auf die Benachrichtigung warten!)

Um die oben beschriebene peinliche Situation zu vermeiden, lesen Sie bitte weiter!

Die Standard-Transaktionsisolationsstufe von Mysql ist Repeatable Read. Verwendet Mysql die Standardisolationsstufe auch in Internetprojekten, ohne Änderungen vorzunehmen?
OK, nein, wir verwenden in unseren Projekten grundsätzlich die Isolationsebene „Read Commitee“!

Was! Es handelt sich tatsächlich um Read Committed. Steht im Internet nicht, dass diese Isolationsebene Probleme不可重復讀und幻讀hat? Mach dir keine Sorgen? Okay, beginnen wir diesen Artikel mit unseren Fragen!

Text

Lassen Sie uns zunächst über eine Frage nachdenken. In Oracle und SqlServer ist Read Commited als Standardisolationsebene ausgewählt. Warum wählt MySQL nicht Read Commited als Standardisolationsebene, sondern Repeatable Read als Standardisolationsebene?

Warum? Warum? Warum?

Dies hat historische Gründe und natürlich müssen wir mit unserer Master-Slave-Replikation beginnen!
主從復制，是基于什么復制的？

Es basiert auf Binlog-Replikation! Ich möchte das Konzept von Binlog hier nicht verschieben, sondern einfach verstehen, dass Binlog eine Datei ist, die Datenbankänderungen aufzeichnet ~

binlog有幾種格式？

OK, es gibt drei Arten, nämlich

• Anweisung: zeichnet die Änderung der SQL-Anweisung auf
• Zeile: zeichnet die Änderungen der tatsächlichen Daten in jeder Zeile auf
• Gemischt: eine Mischung aus Anweisungs- und Zeilenmodi

Vor MySQL 5.0 unterstützt Binlog nur das STATEMENT -Format! Dieses Format weist jedoch einen Fehler bei der Master-Slave-Replikation unter der Isolationsebene „Read Commited“ auf, sodass MySQL „Repeatable Read“ als Standardisolationsebene verwendet!
Lassen Sie uns als Nächstes darüber sprechen, welche Fehler auftreten, wenn das Binlog im STATEMENT -Format vorliegt und die Isolationsebene „Read Commited“ ist. Führen Sie, wie in der folgenden Abbildung dargestellt, die folgende Transaktion auf dem Master aus

Führen Sie zu diesem Zeitpunkt die folgende Anweisung auf dem Master aus

wähle * aus Test;

Die Ausgabe lautet wie folgt

+---+
| b |
+---+
| 3 |
+---+
1 Reihe im Set

Wenn Sie diese Anweisung jedoch zu diesem Zeitpunkt auf dem Slave ausführen, lautet die Ausgabe wie folgt

Leeres Set

Auf diese Weise tritt das Problem der Master-Slave-Inkonsistenz auf! Der Grund ist eigentlich ganz einfach, nämlich die Ausführungsreihenfolge auf dem Master ist: zuerst löschen, dann einfügen! Derzeit liegt das Binärprotokoll im STATEMENT-Format vor und die Reihenfolge der Datensätze ist „Erst einfügen, dann löschen“! Der Slave synchronisiert mit Binglog, daher stimmt die Ausführungsreihenfolge des Slaves nicht mit der des Masters überein! Master-Slave

Inkonsistent!

Wie kann man das Problem lösen?

Es gibt zwei Lösungen!
(1) Die Isolationsebene ist auf „Wiederholbares Lesen“ eingestellt und unter dieser Isolationsebene werden Lückensperren eingeführt. Wenn Session 1 die Löschanweisung ausführt, wird die Lücke geschlossen. Dann wird Ssession 2 beim Ausführen der Insert-Anweisung blockiert!
(2) Ändern Sie das Format von Binglog in das Zeilenformat. Dies ist eine zeilenbasierte Replikation, daher gibt es natürlich kein Problem mit unterschiedlichen SQL-Ausführungsreihenfolgen! Dieses Format wurde jedoch erst mit MySQL Version 5.1 eingeführt. Aus historischen Gründen setzt MySQL daher die Standardisolationsstufe auf „Wiederholbares Lesen“, um sicherzustellen, dass bei der Master-Slave-Replikation keine Probleme auftreten!

Nachdem wir nun verstanden haben, warum MySQL „Repeatable Read“ als Standardisolationsebene wählt, vergleichen wir es mit „Read Commited“, um zu erklären, warum die Isolationsebene in Internetprojekten auf „Read Commited“ eingestellt ist!

Kontrast

Ok, lassen Sie uns zuerst eines verstehen! Die beiden Isolationsebenen Read UnCommitted und Serializable werden im Projekt aus zwei Gründen nicht verwendet.

• Mit Read UnCommitted liest eine Transaktion Daten, die nicht von einer anderen Transaktion festgeschrieben wurden. Das ist natürlich unlogisch!
• Bei Verwendung der Serialisierung (Serializable) wird jeder Lesevorgang gesperrt und Snapshot-Lesevorgänge sind ungültig. Diese Isolationsebene wird im Allgemeinen bei Verwendung der integrierten verteilten Transaktionsfunktion von MySQL verwendet! (Ich habe diese Funktion von MySQL nie verwendet, da es sich um eine XA-Transaktion, eine Transaktion mit starker Konsistenz, handelt und die Leistung schlecht ist! In verteilten Internetlösungen werden meistens Lösungen für Transaktionen mit eventueller Konsistenz verwendet!)

Mit anderen Worten, es gibt nur eine Frage, die uns Sorgen bereiten sollte: Soll die Isolationsebene auf „Read Committed“ oder „Repeatable Read“ lauten?
Lassen Sie uns als Nächstes diese beiden Ebenen vergleichen und darüber sprechen, warum wir „Read Commited“ als Transaktionsisolationsebene wählen!
Angenommen, die Tabellenstruktur ist wie folgt

 CREATE TABLE `test` (
`id` int(11) NICHT NULL,
`color` varchar(20) NICHT NULL,
PRIMÄRSCHLÜSSEL (`id`)
) ENGINE=InnoDB

Die Daten sind wie folgt

+----+--------+
| ID | Farbe |
+----+--------+
| 1 | rot |
| 2 | weiß |
| 5 | rot |
| 7 | weiß |
+----+--------+

Zur Vereinfachung der Beschreibung folgt

• Wiederholbares Lesen, bezeichnet als RR;
• Read Commitee (kurz RC);

Grund 1: Auf der RR-Isolationsebene gibt es eine Lückensperre, wodurch die Wahrscheinlichkeit eines Deadlocks viel größer ist als bei RC!
Führen Sie die Anweisung jetzt aus

Wählen Sie * aus dem Test, wobei die ID <3 für die Aktualisierung ist;

Auf der RR-Isolationsebene gibt es eine Lückensperre, die die Lücke (2,5) sperren kann, um zu verhindern, dass andere Transaktionen Daten einfügen!
Auf der RC-Isolationsebene gibt es jedoch keine Lückensperre und andere Transaktionen können Daten einfügen!

ps : Deadlock bedeutet nicht, dass es auf der RC-Isolationsebene keinen Deadlock geben wird, aber die Wahrscheinlichkeit des Auftretens ist geringer als bei RR!

Grund 2: Wenn die Bedingungsspalte unter der RR-Isolationsebene den Index nicht erreicht, wird die Tabelle gesperrt! In der RC-Isolationsebene werden nur Zeilen gesperrt <br /> Zu diesem Zeitpunkt wird die Anweisung ausgeführt

Testsatz aktualisieren Farbe = „blau“, wobei Farbe = „weiß“;

Auf der RC-Isolationsebene durchläuft es zuerst den gruppierten Index und führt einen vollständigen Scan durch. Das Schloss ist wie folgt:

In der Praxis wurde MySQL jedoch optimiert. Wenn MySQL Server die Bedingungen filtert und feststellt, dass sie nicht erfüllt sind, ruft es die Methode unlock_row auf, um die Datensätze zu sperren, die die Bedingungen nicht erfüllen.

Die eigentliche Verriegelung erfolgt wie folgt

Auf der RR-Isolationsebene wird der gruppierte Index jedoch vollständig gescannt und die gesamte Tabelle gesperrt, wie unten gezeigt:

Grund drei: Auf der RC-Isolationsebene erhöht die halbkonsistente Lesefunktion die Parallelität von Aktualisierungsvorgängen!

In 5.1.15 führte InnoDB ein Konzept namens „semi-konsistent“ ein, das Konflikte beim Aktualisieren derselben Datensatzzeile verringert und die Wartezeiten bei Sperren verkürzt.
Das sogenannte halbkonsistente Lesen bedeutet, dass, wenn eine Update-Anweisung eine Zeile gesperrter Datensätze liest, InnoDB die zuletzt übermittelte Version des Datensatzes zurückgibt und die obere MySQL-Ebene bestimmt, ob diese Version die Update-Where-Bedingung erfüllt. Wenn die Bedingung erfüllt ist (Aktualisierung erforderlich), initiiert MySQL einen neuen Lesevorgang und liest dieses Mal die neueste Version der Zeile (und sperrt sie)!
Die spezifischen Leistungen sind wie folgt:
Derzeit gibt es zwei Sitzungen, Sitzung1 und Sitzung2!
Ausführung von Session1

Testsatz aktualisieren Farbe = „blau“, wobei Farbe = „rot“;

Führen Sie die Transaktion noch nicht durch!
Gleichzeitig wird Session2 ausgeführt

Testsatz aktualisieren Farbe = „blau“, wobei Farbe = „weiß“;

Wenn Sitzung 2 versucht, die Zeile zu sperren, stellt sie fest, dass für die Zeile bereits eine Sperre vorhanden ist. InnoDB aktiviert semikonsistentes Lesen und gibt die zuletzt festgeschriebenen Versionen (1, rot), (2, weiß), (5, rot) und (7, weiß) zurück. MySQL startet den Lesevorgang erneut und liest dieses Mal die neueste Version der Zeile (und sperrt sie)!
Auf der RR-Isolationsebene kann Sitzung2 nur warten!

Zwei Fragen

Muss das Problem des nicht wiederholbaren Lesens auf RC-Ebene gelöst werden?
Es besteht keine Notwendigkeit, es zu lösen, dieses Problem ist akzeptabel! Schließlich sind Ihre Daten ja schon übermittelt, das Auslesen stellt also kein großes Problem dar! Die Standardisolationsstufe von Oracle ist RC. Haben Sie die Standardisolationsstufe von Oracle schon einmal geändert?

Welches Binlog-Format wird auf RC-Ebene für die Master-Slave-Replikation verwendet?
OK, unter dieser Isolationsebene ist das verwendete Binärprotokoll im Zeilenformat, was einer zeilenbasierten Replikation entspricht! Der Gründer von Innodb empfiehlt auch, dieses Format für Binlog zu verwenden!

Zusammenfassen

Dieser Artikel soll nur eines erklären: Für Internetprojekte verwenden Sie bitte die Isolationsstufe „Read Commited“!

Dies ist das Ende dieses Artikels über die Auswahl der Transaktionsisolationsebene in MySQL-Projekten. Weitere Informationen zu MySQL-Transaktionsisolationsebenen finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!