Wie erreicht MySQL die Parallelität mehrerer Versionen?

MySQL-Mehrversionen-Parallelität

1. Steuerung der Parallelität mehrerer Versionen

Wir wissen, dass nicht festgeschriebene Lesevorgänge zu Dirty Reads, Phantom Reads und nicht wiederholbaren Lesevorgängen führen, festgeschriebene Lesevorgänge zu Phantom Reads und nicht wiederholbaren Lesevorgängen führen, wiederholbare Lesevorgänge Phantom Reads aufweisen können und dass diese Probleme bei der Serialisierung nicht auftreten.

Wie also löst InnoDB diese Probleme? Oder haben Sie schon einmal über die zugrundeliegenden und grundlegenden Ursachen von Dirty Reads, Phantom Reads und nicht wiederholbaren Reads nachgedacht?

Dies ist der Protagonist, über den wir heute sprechen werden – MVCC (Multi-Version Concurrent Controll), auch bekannt als Multi-Version Concurrent Control. InnoDB ist eine Speicher-Engine, die mehrere gleichzeitige Transaktionen unterstützt. Sie ermöglicht die gleichzeitige Ausführung von Lese- und Schreibvorgängen in der Datenbank und vermeidet so Leseblockierungen aufgrund von Sperren.

Dank MVCC wird der Lesevorgang von Transaktion A mit ID=1 nicht blockiert, wenn Transaktion B die Daten mit ID=1 aktualisiert. Der Grund für die Nichtblockierung ist konsistentes Lesen ohne Sperren . Was also ist konsistentes Lesen?

1. Konsequentes Lesen

Einfach ausgedrückt: Wenn eine Abfrage ausgeführt wird, erstellt InnoDB einen Snapshot der Datenbank zum aktuellen Zeitpunkt. Nachdem der Snapshot erstellt wurde, kann die aktuelle Abfrage nur die Transaktionsänderungen erkennen, die vor der Erstellung des Snapshots übermittelt wurden. Transaktionen, die nach der Erstellung des Snapshots übermittelt wurden, werden von der aktuellen Abfrage nicht erkannt.

Eine Ausnahme bilden natürlich Daten, die durch die aktuelle Transaktion selbst aktualisiert werden. Die von der aktuellen Transaktion geänderten Zeilen können beim erneuten Lesen die neuesten Daten erhalten. Für andere Zeilen ist die gelesene Version immer noch die Version zum Zeitpunkt der Erstellung des Snapshots .

Dieser Snapshot ist der Schlüssel zur Transaktionsisolationsebene von InnoDB.

Auf der Isolationsebene （Read Committed wird bei jedem konsistenten Lesevorgang in einer Transaktion ein Snapshot neu generiert. Auf der Isolationsebene „Wiederholbares Lesen“ verwenden alle konsistenten Lesevorgänge in einer Transaktion nur den Snapshot, der durch den ersten konsistenten Lesevorgang generiert wurde.

Aus diesem Grund sind in der obigen Abbildung die Änderungen nach dem Commit der Transaktion B unter der Isolationsstufe „Read Committed“ sichtbar, jedoch nicht unter der Isolationsstufe „Repeatable Read“. Dies liegt im Wesentlichen daran, dass der Read-Commit- Snapshot neu generiert wird .

In den Isolationsebenen „Read Committed“ und „Repeatable Read“ verwendet die SELECT-Anweisung standardmäßig ein konsistentes Lesen, und im Szenario des konsistenten Lesens werden keine Sperren hinzugefügt. Andere Änderungsvorgänge können auch synchron durchgeführt werden, was die Leistung von MySQL erheblich verbessert. Dies ist das Implementierungsprinzip der MVCC-Mehrversionen-Parallelitätskontrolle. Diese Art des Lesens wird auch als Snapshot-Lesen bezeichnet.

Was ist, wenn ich während einer Transaktion sofort die Übermittlung anderer Transaktionen sehen möchte? Es gibt zwei Möglichkeiten:

(1) Verwenden Sie die Isolationsstufe „Read Committed“. (2) Sperren Sie die SELECT Anweisung, entweder mit einer gemeinsamen Sperre oder einer exklusiven Sperre. Genauer gesagt: FOR SHARE und FOR UPDATE
Wenn die Sperre, die in der zweiten Methode zum entsprechenden Datensatz hinzugefügt wird, sich gegenseitig ausschließt und die Sperre, die durch SELECT hinzugefügt wird, wird SELECT natürlich blockiert. Diese Art des Lesens wird auch als aktuelles Lesen bezeichnet.

Nachdem Sie die obige Erklärung verstanden haben, können Sie es Ihnen beim nächsten Mal, wenn Sie jemand fragt, wie MVCC implementiert wird, aus der Perspektive konsistenter Lesevorgänge (Snapshot-Lesevorgänge) und aktueller Lesevorgänge erklären und auch den Aktualisierungsmechanismus für konsistente Lese-Snapshots unter verschiedenen Isolationsebenen erläutern.

Aber ich glaube, das reicht nicht, ich sollte es weiterhin gründlich verstehen. Da wir nur einen Schnappschuss kennen, wie wird es auf der untersten Ebene implementiert? Eigentlich weiß ich es immer noch nicht.

2. Vertieftes Verständnis des Prinzips des konsistenten Lesens

Es liegt auf der Hand, dass bei unterschiedlichen konsistenten Lesevorgängen unterschiedliche Versionen der Daten gelesen werden können. Diese müssen daher in MySQL gespeichert werden, da sie sonst nicht gelesen werden können. Ja, diese Daten werden im InnoDB-Tablespace und genauer gesagt im Undo-Tablespace gespeichert.

Der Schlüssel zur Implementierung von MVCC in InnoDB sind eigentlich drei Felder, und jede Zeile in der Datentabelle hat diese drei Felder:

• Das Feld DB_TRX_ID hat 6 Bytes und wird verwendet, um die eindeutige Kennung der Transaktion zu speichern, die die Datenzeile zuletzt eingefügt oder aktualisiert hat . Sie fragen sich vielleicht: Nur Einfügungen und Aktualisierungen? Was ist mit dem Löschen? Tatsächlich handelt es sich bei der Löschung innerhalb von InnoDB um eine Aktualisierungsoperation , die lediglich ein bestimmtes Flag-Bit in der Zeile aktualisiert, um sie als gelöscht zu kennzeichnen.
• Das Feld DB_ROLL_PTR hat 7 Bytes. Sie können es als Rollback-Zeiger bezeichnen, der auf ein bestimmtes Undo-Protokoll zeigt, das im Rollback-Segment gespeichert ist. Auch wenn die aktuelle Datenzeile aktualisiert wurde, können wir den Rollback-Zeiger immer noch verwenden, um die historischen Versionsdaten vor der Aktualisierung abzurufen.
• Das Feld DB_ROW_ID hat 6 Bytes. Es ist die eindeutige Kennung, die InnoDB der Datenzeile zuweist. Diese eindeutige Kennung steigt monoton an, wenn neue Daten eingefügt werden, genau wie der monoton ansteigende Primärschlüssel, der beim Definieren der Tabellenstruktur definiert wurde. DB_ROW_ID wird in den gruppierten Index aufgenommen, jedoch nicht in andere nicht gruppierte Indizes .

Über DB_ROLL_PTR können Sie das neueste Undo-Protokoll abrufen, und dann verweist jedes entsprechende Undo-Protokoll auf sein vorheriges Undo-Protokoll. Auf diese Weise können verschiedene Versionen verbunden werden, um eine verknüpfte Liste zu bilden. Verschiedene Transaktionen wählen unterschiedliche Versionen aus der verknüpften Liste aus, um sie entsprechend den Anforderungen und Regeln zu lesen. Dadurch wird die gleichzeitige Steuerung mehrerer Versionen realisiert, wie in der folgenden Abbildung dargestellt:

Manche Leute wissen vielleicht nichts über Undo Log. Denken Sie einfach an Folgendes:

Das Undo-Log zeichnet den Datenstatus vor dem Start der Transaktion auf, was ein bisschen wie ein Commit in Git ist. Sie senden ein Commit und beginnen dann mit der Arbeit an einer sehr komplexen Anforderung. Dann verlieren Sie die Fassung und möchten diese Änderungen nicht mehr vornehmen. Sie können direkt mit git reset --hard $last_commit_id einen Rollback durchführen. Das letzte Commit kann als Undo-Log betrachtet werden. Wenn Sie interessiert sind, können Sie sich den MySQL-Absturzwiederherstellungsprozess basierend auf dem Redo-Log und dem Undo-Log ansehen.

2. Zusammensetzung des Undo-Logs

Manche Leute fragen sich vielleicht, ob das Undo-Protokoll nicht gelöscht werden sollte, nachdem die Transaktion festgeschrieben wurde. Warum kann ich über MVCC immer noch frühere Daten überprüfen?

Tatsächlich ist das Undo-Log in InnoDB in zwei Teile unterteilt:

• Undo-Protokoll einfügen
• Undo-Protokoll aktualisieren

Beim Insert Undo Log wird es nur für das Rollback verwendet, wenn bei einer Transaktion ein Fehler auftritt, denn sobald die Transaktion festgeschrieben ist, ist Insert Undo Log völlig nutzlos und wird daher nach dem Festschreiben der Transaktion gelöscht.

Das Update-Undo-Log ist anders. Es kann für MVCC-konsistente Lesevorgänge verwendet werden und stellt eine Datenquelle für Anforderungen verschiedener Versionen bereit. Bedeutet dies also, dass das Update-Undo-Log überhaupt nicht entfernt werden kann? Denn man weiß nicht, wann eine konsistente Lese-Anforderung kommt, wodurch der belegte Speicherplatz immer größer wird.

Ja, aber nicht vollständig.

Konsistentes Lesen bedeutet im Wesentlichen, mehrere Transaktionen gleichzeitig zu verarbeiten, und verschiedenen Transaktionen müssen bei Bedarf unterschiedliche Datenversionen zugewiesen werden . Wenn derzeit keine Transaktion vorhanden ist, kann das Update Undo Log daher beendet werden.

Damit schließen wir den Artikel darüber ab, wie MySQL die Parallelität mehrerer Versionen erreicht. Dies ist das Ende des Artikels. Weitere relevante Inhalte zur MySQL-Mehrversions-Parallelität finden Sie in den vorherigen Artikeln von 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!