Warum MySQL Repeatable Read als Standardisolationsebene wählt

Ich glaube, dass viele Leser mit den Transaktionsisolationsebenen von MySQL vertraut sind. Im Internet gibt es viele entsprechende Artikel. Viele Leute sind mit verschiedenen Isolationsebenen vertraut und lesen einige Phänomene, die durch verschiedene Ebenen gelöst werden können.

Wir wissen , dass es vier Standardisolationsebenen gibt, die durch ANSI/ISO SQL definiert sind, von hoch bis niedrig: Serialisierbar, Wiederholbare Lesevorgänge, Festgeschriebenes Lesen und Nicht festgeschriebenes Lesen.

Auf der RU-Isolationsebene können Probleme wie Dirty Reads, Phantom Reads und nicht wiederholbare Lesevorgänge auftreten. Auf der RC-Isolationsebene wird das Dirty-Read-Problem gelöst, die Phantom-Read- und nicht wiederholbaren Read-Probleme bleiben jedoch bestehen. Auf der RR-Isolationsebene werden die Probleme von Dirty Reads und nicht wiederholbaren Reads gelöst, das Problem von Phantom Reads besteht jedoch weiterhin. Auf der serialisierbaren Isolationsebene werden die Probleme von Dirty Reads, Phantom Reads und nicht wiederholbaren Reads gelöst.

Diese vier Isolationsebenen werden durch den ANSI/ISO-SQL-Standard definiert. Das allgemein verwendete MySQL unterstützt alle vier Isolationsebenen. Die Oracle-Datenbank unterstützt jedoch nur Serializable und Read Committed .

Viele Leute wissen jedoch möglicherweise nicht, dass die Standardisolationsstufe von Oracle RC ist, während die Standardisolationsstufe von MySQL RR ist.

Wissen Sie also, warum Oracle RC als Standardebene und MySQL RR als Standardisolationsebene wählt?

Diese Frage habe ich den Kandidaten in früheren Vorstellungsgesprächen gestellt.

Viele Leute denken, dass diese Frage bedeutungslos ist. Zwingt uns das nicht, achtbeinige Aufsätze auswendig zu lernen?

Aber eigentlich ist es das nicht. Wenn Sie diesen Artikel geduldig lesen, werden Sie meine guten Absichten erkennen.

Oracle-Isolationsebenen

Wie bereits erwähnt, unterstützt Oracle nur Serializable und Read Committed, die in ANSI/ISO SQL definiert sind. Laut der Einführung in den offiziellen Oracle-Dokumenten unterstützt Oracle tatsächlich drei Isolationsebenen:

Das heißt, Oracle unterstützt Read Committed, Serializable und Read-Only.

Die Isolationsebene „Nur lesen“ ähnelt der Isolationsebene „Serialisierbar“, allerdings lassen schreibgeschützte Transaktionen keine Datenänderungen innerhalb der Transaktion zu, es sei denn, der Benutzer ist SYS.

Unter den drei Isolationsebenen von Oracle sind Serializable und Read-Only offensichtlich nicht als Standardisolationsebene geeignet, daher ist Read Committed die einzige verbleibende Option.

MySQL-Isolationsebenen

Im Vergleich zu Oracle bietet MySQL eine größere Auswahl an Standardisolationsebenen.

Zunächst schließen wir Serializable und Read Uncommitted von den vier Isolationsebenen aus, hauptsächlich weil eine dieser beiden Isolationsebenen zu hoch und die andere zu niedrig ist. Ist der Wert zu hoch, wirkt sich dies auf die Parallelität aus, ist er zu niedrig, kommt es zu Dirty Reads.

Wie also wählt man zwischen den beiden verbleibenden Typen, RR und RC?

Diese Geschichte begann vor langer, langer Zeit.

Ziel bei der Entwicklung von MySQL war die Bereitstellung einer stabilen relationalen Datenbank. Um das durch einen MySQL-Einzelpunktausfall verursachte Problem zu lösen, verwendet MySQL den Master-Slave-Replikationsmechanismus.

Die sogenannte Master-Slave-Replikation dient eigentlich dazu, einen MySQL-Cluster aufzubauen, der der Außenwelt als Ganzes Dienste bereitstellt. Die Maschinen im Cluster sind in Master-Server (Master) und Slave-Server (Slave) unterteilt. Der Master-Server bietet Schreibdienste und der Slave-Server bietet Lesedienste.

Um die Datenkonsistenz zwischen Master- und Slave-Server sicherzustellen, ist eine Datensynchronisierung erforderlich. Der allgemeine Synchronisierungsprozess läuft wie folgt ab und wird hier nicht im Detail beschrieben.

Im Prozess der MySQL-Master-Slave-Replikation wird die Datensynchronisation über das Bin-Protokoll durchgeführt . Einfach ausgedrückt zeichnet der Master-Server Datenänderungen im Bin-Protokoll auf und überträgt das Bin-Protokoll dann synchron an den Slave-Server. Nachdem der Slave-Server das Bin-Protokoll empfangen hat, stellt er die darin enthaltenen Daten in seinem eigenen Datenbankspeicher wieder her.

Also, was wird im Binlog aufgezeichnet? Wie ist das Format?

Das Binärprotokoll von MySQL unterstützt hauptsächlich drei Formate: Anweisung, Zeile und gemischt. MySQL unterstützt seit Version 5.1.5 auch Row und seit Version 5.1.8 Mixed.

Der größte Unterschied zwischen Anweisung und Zeile besteht darin , dass, wenn das Binlog-Format „Statements“ ist, das Binlog den Originaltext der SQL-Anweisung aufzeichnet (dieser Satz ist sehr wichtig!!! Er wird später verwendet).

Die Unterschiede zwischen diesen Formaten werden hier nicht näher erläutert. Der Grund für die Unterstützung des Zeilenformats liegt hauptsächlich darin, dass das Anweisungsformat viele Probleme aufweist. Das offensichtlichste ist, dass es zu Dateninkonsistenzen zwischen der Master- und der Slave-Datenbank führen kann. Eine ausführliche Einführung finden Sie in Ding Qis Beitrag „45 Vorlesungen zur MySQL-Praxis“ auf Geek Time.

Welche Beziehung besteht also zwischen dieser Master-Slave-Synchronisierung und der Isolationsebene, über die wir im Binärprotokoll sprechen werden?

Ja, es ist wichtig und eine große Sache.

Da MySQL in der Anfangszeit nur über das Anweisungs-Bin-Protokollformat verfügte, traten Probleme auf, wenn die beiden Isolationsebenen Read Committed und Read Uncommitted verwendet wurden.

Beispielsweise meldete jemand auf der offiziellen MySQL-Website einmal einen entsprechenden Fehler an die offizielle

Der Prozess zur Reproduktion dieses Fehlers läuft wie folgt ab:

Es gibt eine Datenbanktabelle t1, die die folgenden zwei Datensätze enthält:

   Tabelle erstellen t1 (

      ein int(11) DEFAULT NULL,

      b int(11) DEFAULT NULL,

      SCHLÜSSEL a (a)

    )ENGINE=InnoDB STANDARD-CHARSET=latin1;

    in t1 Werte (10,2), (20,1) einfügen;

Beginnen Sie dann mit der Ausführung der Schreibvorgänge der beiden Transaktionen:

Nachdem die beiden oben genannten Transaktionen ausgeführt wurden, werden die Datensätze in der Datenbank zu (11, 2) und (20, 2). Jeder kann die Datenänderungen in der Hauptdatenbank verstehen.

Da die Isolationsebene der Transaktion auf „Read Committed“ (Lesezugriff) eingestellt ist, wird bei der Aktualisierung von Transaktion 1 nur eine Zeilensperre für die Zeile b=2 hinzugefügt. Dies hat keine Auswirkungen auf den Schreibvorgang von Transaktion 2 für die Zeile b=1.

Nachdem die beiden oben genannten Transaktionen ausgeführt wurden, werden zwei Datensätze im Bin-Protokoll aufgezeichnet. Da Transaktion 2 zuerst festgeschrieben wird, wird zuerst UPDATE t1 SET b=2 where b=1; aufgezeichnet und dann UPDATE t1 SET a=11 where b=2; aufgezeichnet. (Erinnerung: Das Bin-Protokoll im Anweisungsformat zeichnet den Originaltext der SQL-Anweisung auf.)

Auf diese Weise wird nach der Synchronisierung des Binärprotokolls mit der Standbydatenbank bei der Wiedergabe der SQL-Anweisung zuerst UPDATE t1 SET b=2 where b=1; ausgeführt und anschließend UPDATE t1 SET a=11 where b=2; ausgeführt.

Zu diesem Zeitpunkt werden die Daten in der Datenbank zu (11, 2) und (11, 2). Dies führt zu inkonsistenten Daten zwischen der Hauptdatenbank und der Backup-Datenbank! ! !

Um zu vermeiden, dass solche Probleme auftreten. MySQL setzt die Standardisolationsebene der Datenbank auf „Repetable Read“. Wie also löst die Isolationsebene „Repetable Read“ dieses Problem?

Dies liegt daran, dass die Isolationsebene „Repetable Read“ beim Aktualisieren von Daten nicht nur Zeilensperren zu den aktualisierten Zeilen hinzufügt, sondern auch GAP-Sperren hinzufügt. Im obigen Beispiel bleibt bei der Ausführung von Transaktion 2 die Ausführung der Transaktion hängen, weil Transaktion 1 eine GAP-Sperre hinzufügt. Die Transaktion muss warten, bis Transaktion 1 festgeschrieben oder zurückgesetzt wurde, bevor sie fortgesetzt werden kann. (Zur GAP-Sperre werde ich später einen separaten Artikel schreiben).

Zusätzlich zum Festlegen der Standardisolationsebene verbietet MySQL auch die Verwendung von READ COMMITTED als Transaktionsisolationsebene bei der Verwendung von Binärprotokollen im Anweisungsformat.

Sobald der Benutzer die Isolationsebene aktiv ändert, wird beim Versuch der Aktualisierung ein Fehler gemeldet:

  FEHLER 1598 (HY000): Binäres Logging nicht möglich. Meldung: Transaktionsebene 'READ-COMMITTED' in InnoDB ist für den Binärlog-Modus 'STATEMENT' nicht sicher.

Zusammenfassen

Jetzt wissen wir also, warum MySQL RR als Standardisolationsebene für Datenbanken wählt. Tatsächlich dient es dazu, mit dem historischen Anweisungsformat Bin-Log kompatibel zu sein.

Dieser Artikel hat also weniger als 1/5 des Wissens über die MySQL-Isolationsebene abgedeckt. Nach dem Lesen dieses Artikels haben Sie möglicherweise noch die folgenden Fragen:

1. Was ist der Unterschied zwischen Zeilenformat und Anweisung? Kann RR bei Verwendung von Row verwendet werden?

2. Was genau ist das im Artikel erwähnte RC GAP-Schloss?

3. Was ist der Unterschied zwischen RR und RC? Wie löst RC das Problem des nicht wiederholbaren Lesens?

4. Da die MySQL-Datenbank standardmäßig RR auswählt, warum sollte ein großes Internetunternehmen wie Alibaba die Standardisolationsebene auf RC ändern?

Kennen Sie die Antworten auf die oben stehenden Fragen oder welche davon interessiert Sie mehr? Hinterlassen Sie gerne eine Nachricht! Die für euch interessanteren Themen suche ich mir aus und stelle sie in den folgenden Artikeln immer ausführlicher vor.

Glauben Sie immer noch, dass diese Frage bedeutungslos ist?

Eigentlich möchte ich durch eine solche scheinbar nichtssagende Frage mein Wissen erweitern, um ein umfassenderes Bild vom Kandidaten zu bekommen.

Damit ist dieser Artikel darüber, warum MySQL Repeatable Read als Standardisolationsstufe wählt, abgeschlossen. Weitere Informationen zur Standardisolationsstufe von MySQL Repeatable Read finden Sie in den vorherigen Artikeln von 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!