Detaillierte Untersuchung der MySQL-Mehrversions-Parallelitätskontrolle MVCC

MVCC

MVCC (Multi-Version Concurrency Control) ist eine Mehrversionen-Parallelitätskontrolle. Eine wichtige Funktion von InnoDB besteht darin, gleichzeitige Transaktionen und Rollbacks zu realisieren. Der Sperrmechanismus kann gleichzeitige Vorgänge steuern, hat jedoch einen hohen Systemaufwand. In den meisten Fällen kann MVCC Sperren auf Zeilenebene ersetzen. Die Verwendung von MVCC kann den Systemaufwand verringern.

Die konkrete Implementierung besteht darin, jeder Zeile der Datenbank drei zusätzliche Felder hinzuzufügen:

1. DB_TRX_ID: zeichnet die Transaktions-ID der letzten Transaktion auf, die die Zeile eingefügt oder aktualisiert hat
2. DB_ROLL_PTR: Zeiger auf das Undolog, das der Zeilenänderung entspricht
3. DB_ROW_ID: Monoton zunehmende ID, die die Primärschlüssel-ID von AUTO_INCREMENT ist

Snapshot lesen

Beispielsweise ist eine entsperrte Auswahloperation ein Snapshot-Lesevorgang. Das Aufkommen des Snapshot-Lesevorgangs basiert auf der Überlegung, die Parallelitätsleistung zu verbessern. Die Implementierung des Snapshot-Lesevorgangs basiert auf der Multiversion-Parallelitätssteuerung, nämlich MVCC. MVCC kann als eine Variante von Zeilensperren betrachtet werden. In vielen Fällen werden Sperrvorgänge vermieden und der Overhead verringert. Da es auf mehreren Versionen basiert, liest der Snapshot-Lesevorgang möglicherweise nicht unbedingt die neueste Version der Daten, sondern kann eine frühere historische Version sein.

Aktueller Messwert

Gelesen werden die aktuellen Daten, und es ist nicht erforderlich, mithilfe des Undo-Protokolls den Zustand vor dem Start der Transaktion zurückzuverfolgen. Gelesen wird die neueste Version des Datensatzes. Beim Lesen muss außerdem sichergestellt werden, dass andere gleichzeitige Transaktionen den aktuellen Datensatz nicht ändern können und der gelesene Datensatz gesperrt wird.

Es gibt drei Datenbank-Parallelitätsszenarien:

• Lesen-Lesen: Keine Probleme, keine Notwendigkeit für Parallelitätskontrolle
• Lesen/Schreiben: Es gibt Thread-Sicherheitsprobleme, die zu Problemen mit der Transaktionsisolierung führen können und zu Dirty Reads, Phantom Reads und nicht wiederholbaren Lesevorgängen führen können.
• Schreiben-Schreiben: Es gibt Thread-Sicherheitsprobleme und es kann zu Update-Verlustproblemen kommen, wie z. B. der erste Typ von Update-Verlust und der zweite Typ von Update-Verlust

Einfach ausgedrückt soll MVCC Lese-/Schreibkonflikte ohne Sperren erreichen, und dieser Lesevorgang bezieht sich auf das Lesen eines Snapshots, nicht auf das aktuelle Lesen. Das aktuelle Lesen ist eigentlich ein Sperrvorgang, der die Implementierung einer pessimistischen Sperre darstellt.

Das Aufkommen von MVCC liegt darin begründet, dass die Großen nicht damit zufrieden sind, pessimistische Sperren zur Lösung des Lese-/Schreibkonfliktproblems zu verwenden. Daher gibt es zwei Lösungen:

• MVCC + pessimistische Sperre
  MVCC löst Lese-/Schreibkonflikte, und pessimistische Sperren lösen Schreib-/Schreibkonflikte
• MVCC + optimistische Sperre
  MVCC löst Lese-/Schreibkonflikte, und optimistisches Sperren löst Schreib-/Schreibkonflikte

MVCC-Implementierungsprinzip

Drei versteckte Felder

• DB_TRX_ID
  6 Bytes, zuletzt geänderte (ändern/einfügen) Transaktions-ID: zeichnet die Transaktions-ID auf, die diesen Datensatz erstellt/zuletzt geändert hat
• DB_ROLL_PTR
  7 Bytes, Rollback-Zeiger, der auf die vorherige Version dieses Datensatzes zeigt (im Rollback-Segment gespeichert)
• DB_ROW_ID
  6 Bytes, implizite Auto-Inkrement-ID (versteckter Primärschlüssel). Wenn die Datentabelle keinen Primärschlüssel hat, generiert InnoDB automatisch einen Clustered-Index mit DB_ROW_ID

Versionskette/Undo-Protokoll

Denn das Rückgängig-Protokoll zeichnet die alte Version der Daten vor der Transaktion auf, und dann zeigt der Rollback-Zeiger im Zeilendatensatz auf die Position der alten Version, wodurch eine Versionskette gebildet wird. Die Lese-Ansicht durchläuft die DB_TRX_ID in der verknüpften Liste weiter, bis sie eine DB_TRX_ID findet, die bestimmte Bedingungen erfüllt. Dann ist der alte Datensatz, in dem sich die DB_TRX_ID befindet, die neueste „alte Version“, die die aktuelle Transaktion sehen kann.

Ansicht lesen

Es handelt sich um eine Sammlung aller aktuell aktiven Transaktionen (Transaktionen, die noch nicht festgeschrieben wurden), wenn die Transaktion geöffnet wird. Mit anderen Worten ist die Leseansicht die Leseansicht, die generiert wird, wenn eine Transaktion einen Snapshot-Lesevorgang ausführt. In dem Moment, in dem der Snapshot-Lesevorgang von der Transaktion ausgeführt wird, wird ein Snapshot des aktuellen Datenbanksystems generiert, der die ID der aktuell aktiven Transaktion im System aufzeichnet und verwaltet.

Drei wichtige Read View-Strukturen:

• trx_list (von mir zufällig benannt)
  Eine Liste von Werten, die zur Pflege der Liste der Transaktions-IDs verwendet werden, die zum Zeitpunkt der Generierung der Leseansicht im System aktiv sind
• up_limit_id
  Die kleinste Transaktions-ID in der trx_list-Liste
• Untergrenze-ID

Die nächste Transaktions-ID, die zum Zeitpunkt der ReadView-Generierung noch nicht vom System zugewiesen wurde. Dies ist der Maximalwert der bisher angezeigten Transaktions-ID + 1.

Warum low_limit? Weil es auch der Mindestwert der Transaktions-ID ist, den das System in diesem Moment zuordnen kann.

Der Gesamtprozess der MVCC-Implementierung:

Zusammenfassen

• Bei Transaktionen mit hoher Parallelität ist MVCC effizienter als einfaches Sperren
• MVCC funktioniert nur unter den beiden Isolationsebenen Read Committed und Repeatable Read.
• Auf der Isolationsebene „Read Committed“ wird für jeden Snapshot-Lesevorgang (Abfrage) eine Leseansicht generiert. Beim wiederholbaren Lesen wird nur zu Beginn einer Transaktion eine Leseansicht generiert, und diese Leseansicht wird für jede nachfolgende Abfrage verwendet, um unterschiedliche Isolationsebenen zu erreichen.

siehe:

[MySQL-Hinweise] MySQLs MVCC und Implementierungsprinzipien richtig verstehen (empfohlen)

MySQL · Engine-Funktionen · InnoDB-Transaktionssystem (taobao.org)

Detaillierte Erklärung von mvcc – Jianshu (jianshu.com)

Damit schließen wir diesen Artikel zur eingehenden Untersuchung der MySQL-Mehrversions-Parallelitätskontrolle MVCC ab. Ich hoffe, dass es für jedermanns Studium hilfreich sein wird, und ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.