Implementierung von MySQL Multi-version Concurrency Control MVCC

Was ist MVCC

MVCC steht für Multi-Version Concurrency Control.

Die transaktionale Speicher-Engine von MySQL verbessert die Parallelitätsleistung durch Multi-Version Concurrency Control (MVCC).

MVCC kann als eine Variante der Zeilensperre betrachtet werden, vermeidet jedoch in den meisten Fällen Sperrvorgänge und implementiert nicht blockierende Lesevorgänge, sodass der Overhead geringer ist.

MVCC wird implementiert, indem ein Snapshot der Daten zu einem bestimmten Zeitpunkt gespeichert wird. Die Kernidee besteht darin, historische Versionen von Daten zu speichern und die Datenbank-Parallelitätskontrolle durch die Verwaltung mehrerer Versionen von Datenzeilen zu implementieren.

Auf diese Weise können wir durch Vergleichen der Versionsnummer entscheiden, ob die Daten angezeigt werden sollen, und wir können den Isolationseffekt der Transaktion ohne Sperren beim Lesen der Daten sicherstellen.

MVCC-Implementierung

Tatsächlich fügt InnoDB nach jeder Datensatzzeile drei versteckte Felder hinzu:

• ROW_ID: Zeilen-ID, die beim Einfügen neuer Zeilen monoton ansteigt. Wenn ein Primärschlüssel vorhanden ist, wird diese Spalte nicht eingeschlossen.
• TRX_ID: Zeichnet die Transaktions-ID der Transaktion auf, die die Zeile eingefügt oder aktualisiert hat.
• ROLL_PTR: Rollback-Zeiger, der auf den Undo-Log-Datensatz zeigt. Bei jeder Änderung eines Datensatzes wird in der Spalte ein Zeiger gespeichert, über den die Informationen vor der Änderung des Datensatzes gefunden werden können. Wenn ein Datensatz mehrmals geändert wird, gibt es mehrere Versionen des Zeilendatensatzes, die durch ROLL_PTR verknüpft sind, um ein Konzept zu bilden, das einer Versionskette ähnelt.

Nehmen wir als Beispiel das RR-Level:

Bei jedem Öffnen einer Transaktion weist das System der Transaktion eine Transaktions-ID zu. Wenn die erste Select-Anweisung in der Transaktion ausgeführt wird, wird ein Transaktions-Snapshot ReadView zum aktuellen Zeitpunkt generiert, der im Wesentlichen die folgenden Eigenschaften enthält:

• m_ids: Gibt die Transaktions-ID-Liste nicht festgeschriebener Lese- und Schreibtransaktionen im aktuellen System an, wenn die ReadView generiert wird.
• min_trx_id: Gibt die kleinste Transaktions-ID unter den nicht festgeschriebenen Lese-/Schreibtransaktionen im aktuellen System an, wenn die ReadView generiert wird, d. h. den Mindestwert in m_ids.
• max_trx_id: Gibt den ID-Wert an, der beim Generieren eines ReadView der nächsten Transaktion im System zugewiesen werden soll.
• creator_trx_id: Gibt die Transaktions-ID der Transaktion an, wenn die ReadView generiert wird.

Mit diesem ReadView müssen Sie beim Zugriff auf einen Datensatz nur die folgenden Schritte ausführen, um festzustellen, ob eine Version des Datensatzes sichtbar ist:

• trx_id == creator_trx_id: kann auf diese Version zugreifen.
• trx_id < min_trx_id: Auf diese Version kann zugegriffen werden.
• trx_id > max_trx_id: Auf diese Version kann nicht zugegriffen werden.
• min_trx_id <= trx_id <= max_trx_id: Wenn trx_id in m_ids ist, kann nicht auf diese Version zugegriffen werden, andernfalls ist sie verfügbar.

Bei der Beurteilung wird zunächst die neueste Version des Datensatzes verglichen. Wenn die Version von der aktuellen Transaktion nicht angezeigt werden kann, wird die vorherige Version über den ROLL_PTR des Datensatzes gefunden und erneut verglichen, bis eine Version gefunden wird, die von der aktuellen Transaktion angezeigt werden kann.
Das Löschen ist eigentlich eine spezielle Aktualisierung. InnoDB verwendet ein zusätzliches Flag-Bit, delete_bit, um anzuzeigen, ob die Daten gelöscht wurden. Wenn wir eine Beurteilung vornehmen, prüfen wir, ob das delete_bit markiert ist. Wenn dies der Fall ist, überspringen wir diese Version und erhalten die nächste Version zur Beurteilung über ROLL_PTR.

Der obige Inhalt gilt für die RR-Ebene. Für die RC-Ebene ist der gesamte Prozess fast derselbe. Der einzige Unterschied besteht im Zeitpunkt der Generierung von ReadView. Die RR-Ebene generiert es nur einmal zu Beginn der Transaktion und dann wird ReadView ständig verwendet. Auf der RC-Ebene wird bei jeder Auswahl ein ReadView generiert.

Löst MVCC Phantom-Lesevorgänge?

Phantomlesen: In einer Transaktion wird dasselbe SQL zweimal zum Lesen verwendet, und das zweite Lesen enthält Zeilen, die von anderen Transaktionen neu eingefügt wurden.
Zum Beispiel:

1) Transaktion 1: Erste Abfrage: select * from user where id < 10 und die Daten mit id = 1 werden gefunden.

2) Transaktion 2 fügt Daten mit der ID = 2 ein

3) Wenn Transaktion 1 zum zweiten Mal dieselbe Anweisung für die Abfrage verwendet, werden Daten mit der ID = 1 und der ID = 2 gefunden und es erfolgt ein Phantomlesen.

Wenn wir über Phantomlesevorgänge sprechen, müssen wir zunächst die Konzepte „aktuelle Lesevorgänge“ und „Schnappschusslesevorgänge“ einführen.

• Snapshot lesen : Erstellen Sie einen Transaktions-Snapshot (ReadView) und rufen Sie dann Daten aus diesem Snapshot ab. Gewöhnliche Select-Anweisungen sind Snapshot-Lesevorgänge.
• Aktueller Lesevorgang : Liest die neueste Version der Daten. Allgemeines Aktualisieren/Einfügen/Löschen, Auswählen … zum Aktualisieren und Auswählen … Sperren im Freigabemodus sind alles aktuelle Lesevorgänge.

Bei Snapshot-Lesevorgängen erkennt MVCC die neu eingefügten Zeilen nicht, da es aus ReadView liest. Daher wird das Problem der Phantom-Lesevorgänge automatisch gelöst.

MVCC kann den Phantomlesevorgang des aktuellen Lesevorgangs jedoch nicht lösen. Sie müssen Gap Lock oder Next-Key Lock (Gap Lock + Record Lock) verwenden, um dieses Problem zu lösen.

Tatsächlich ist das Prinzip sehr einfach. Verwenden Sie das obige Beispiel, um es leicht abzuändern und den aktuellen Lesevorgang auszulösen:

Wählen Sie * vom Benutzer, bei dem die ID < 10 ist, für die Aktualisierung

Wenn Gap Lock verwendet wird, sperrt Gap Lock den gesamten Bereich der IDs < 10, sodass andere Transaktionen keine Daten mit IDs < 10 einfügen können. Dadurch werden Phantomlesevorgänge verhindert.

Dies ist das Ende dieses Artikels über die Implementierung der MySQL-Mehrversions-Parallelitätskontrolle MVCC. Weitere relevante Inhalte zur MySQL-Mehrversions-Parallelitätskontrolle MVCC finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!