Eine kurze Analyse von MySQL - MVCC

Versionskette

In den Tabellen der InnoDB-Engine gibt es in den Clustered-Index-Datensätzen zwei versteckte Spalten:

• trx_id: wird zum Speichern der Transaktions-ID beim Ändern von Daten verwendet
• roll_pointer: Jedes Mal, wenn ein Clustered-Index-Datensatz geändert wird, wird die alte Version in das Undo-Protokoll geschrieben. Dieser Roll_Pointer speichert einen Zeiger, der auf den Speicherort der vorherigen Version dieses Clustered-Index-Datensatzes zeigt, über den die Datensatzinformationen der vorherigen Version abgerufen werden können.

Beispielsweise gibt es eine Transaktion mit TRX_ID 60, die die folgende Anweisung ausführt: Update Table Set Name = 'Xiaoming1', wobei ID = 1

An dieser Stelle gibt es eine Versionskette im Undo-Log

Die Versionskette kann git ähneln, das eine Versionskontrolle für eine Datenzeile durchführen und über undo_log zurückgesetzt werden kann

LesenAnzeigen

Der Unterschied zwischen Read Committed und Repeatable Read besteht darin, dass sie unterschiedliche Strategien zum Generieren von ReadView haben.

ReadView verfügt hauptsächlich über eine Liste zum Speichern der aktuell aktiven Lese- und Schreibtransaktionen in unserem System (Beginn der Transaktion, die noch nicht festgeschrieben wurde). Mithilfe dieser Liste wird ermittelt, ob eine Version des Datensatzes für die aktuelle Transaktion sichtbar ist. Angenommen, die Transaktions-ID in der aktuellen Liste ist [80,100].

ID <= 80 (minimale Transaktions-ID)
ID >= 80 und ID <= 100
Ich würde >= 100

Diese Datensätze werden in der Versionskette durchsucht. Dabei wird zuerst der aktuellste Datensatz durchsucht. Erfüllt die Transaktions-ID des aktuellsten Datensatzes die Bedingungen nicht und ist er nicht sichtbar, wird die vorherige Version durchsucht und die ID der aktuellen Transaktion mit der Transaktions-ID dieser Version verglichen, um zu sehen, ob auf diese zugegriffen werden kann. Dieser Vorgang wird so lange wiederholt, bis eine sichtbare Version zurückgegeben wird oder der Vorgang beendet wird.

Beispielsweise in der Isolationsebene „Read Committed“:

Beispielsweise gibt es zu diesem Zeitpunkt eine Transaktion mit der Transaktions-ID 100, die den Namen so ändert, dass er „Xiaoming 2“ lautet, die Transaktion wurde jedoch noch nicht festgeschrieben. Die Versionskette zu diesem Zeitpunkt ist

Zu diesem Zeitpunkt initiiert eine andere Transaktion eine Select-Anweisung, um den Datensatz mit der ID 1 abzufragen, und die generierte ReadView-Liste ist nur [100]. Gehen Sie dann zur Versionskette, um sie zu finden. Zuerst müssen Sie die aktuellste Version finden. Sie werden feststellen, dass trx_id 100 ist, was der Datensatz mit dem Namen Xiaoming 2 ist. Er befindet sich in der Liste, daher kann nicht darauf zugegriffen werden.

Zu diesem Zeitpunkt suchen wir weiter über den Zeiger nach dem nächsten Datensatz mit dem Namen Xiaoming 1 und stellen fest, dass trx_id 60 ist, was kleiner als die Mindest-ID in der Liste ist, sodass darauf zugegriffen werden kann. Das direkte Zugriffsergebnis ist Xiaoming 1.

Zu diesem Zeitpunkt bestätigen wir die Transaktion mit der Transaktions-ID 100 und erstellen eine neue Transaktion mit der ID 110, um den Datensatz mit der ID 1 zu ändern, und bestätigen die Transaktion nicht.

--trx_id = 110
BEGINNEN;
Tabellensatzname aktualisieren = „Xiaoming3“, wobei ID = 1

Zu diesem Zeitpunkt ist die Versionskette

Zu diesem Zeitpunkt hat die vorherige Auswahltransaktion eine weitere Abfrage ausgeführt, um den Datensatz mit der ID 1 abzufragen.

Unterschiedliche Isolationsstufen führen hier zu unterschiedlichen Ergebnissen

Wenn Sie sich in der Isolationsebene für festgeschriebenes Lesen befinden, erstellen Sie zu diesem Zeitpunkt eine neue ReadView und der Wert in Ihrer Liste aktiver Transaktionen ändert sich auf [110].

Gemäß der obigen Anweisung gehen Sie zur Versionskette und vergleichen trx_id, um das entsprechende Ergebnis zu finden, nämlich Xiao Ming 2.

Wenn Sie sich in der wiederholbaren Leseisolationsebene befinden, ist Ihr ReadView immer noch das ReadView, das während der ersten Auswahl generiert wurde, d. h. der Wert der Liste ist immer noch [100]. Das Ergebnis der Auswahl ist also Xiao Ming 1. Das Ergebnis der zweiten Auswahl ist also dasselbe wie das der ersten, es wird also als wiederholbares Lesen bezeichnet!

Dies ist MySQLs MVCC, das mehrere Versionen über Versionsketten implementiert und gleichzeitige Lese-/Schreib- und Schreib-/Lesevorgänge ausführen kann. Durch unterschiedliche Strategien zur ReadView-Generierung werden unterschiedliche Isolationsstufen erreicht.

Das Obige ist eine kurze Analyse der Details von MySQL - MVCC. Weitere Informationen zu MySQL MVCC finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!