Wie wird die Isolationsstufe von MySQL implementiert?

Implementierungsmethode der MySQL-Isolationsstufe: Wenn die Isolationsstufe nicht festgeschriebenes Lesen ist, sind alle Lesevorgänge nicht gesperrt, die gelesenen Daten sind die neuesten Daten, die Leistung ist am besten und alle Schreibvorgänge erfolgen auf Zeilenebene. Veröffentlichung nach dem Schreiben. Wenn die Isolationsstufe Serialisierung ist, sind sowohl Lesen als auch Schreiben gesperrt.

Isolationsstufe

(empfohlenes Tutorial: MySQL-Tutorial )

Es gibt 4 Isolationsstufen für Datenbanktransaktionen: „Lesen nicht festgeschrieben“, „Lesen festgeschrieben“, „Wiederholbares Lesen“ und „Serialisierbar“. Jede Stufe kann die Probleme von schmutzigen Lesevorgängen, nicht wiederholbaren Lesevorgängen und Phantom-Lesevorgängen einzeln lösen .

Implementierung auf Isolationsebene:

Uncommitted Read (RU: read-uncommitted):

auf RU-Ebene, alle Daten Von der Transaktion gelesen werden die neuesten Daten, bei denen es sich um Daten nach der Übermittlung der Transaktion oder um Daten während der Transaktionsausführung (die möglicherweise zurückgesetzt werden können) handeln kann.

Wenn die Isolationsstufe RU ist:

• Alle Lesevorgänge sind nicht gesperrt und die gelesenen Daten sind die neuesten Daten mit der besten Leistung.

• Fügen Sie allen Schreibvorgängen Sperren auf Zeilenebene hinzu und geben Sie sie nach dem Schreiben frei.

Read-Committed (RC: Read-Committed):

Verwenden Sie die MVCC-Technologie, um versteckte Felder zu jeder Zeile hinzuzufügen (DB_TRX_ID: Ändern Sie die Die ID der letzten Transaktion der Zeile, DB_ROLL_PTR: zeigt auf das Rückgängig-Protokoll der aktuellen Zeile, DB_ROW_ID: Zeilenkennung, DELETE_BIT: Löschflag), das nicht gesperrte Lesevorgänge implementiert.

Wenn die Isolationsstufe RC ist:

• Schreibvorgang: Sperre auf Zeilenebene hinzufügen. Nach dem Start der Transaktion wird ein Änderungsdatensatz in das UNDO-Protokoll geschrieben und die ausgeblendete Spalte DATA_POLL_PTR in der Datenzeile speichert einen Zeiger auf den UNDO-Datensatz der Zeile.

• Lesevorgang: Keine Sperrung. Wenn die Zeile beim Lesen durch andere Transaktionen gesperrt ist, folgen Sie dem ausgeblendeten Spaltenzeiger DATA_POLL_PTR, um den vorherigen gültigen historischen Datensatz zu finden (gültiger Datensatz: Dieser Datensatz ist für die aktuelle Transaktion sichtbar und DELETE_BIT = 0).

Wiederholbares Lesen (RR: Repeatable-Read):

Verwenden Sie die MVCC-Technologie, um sperrfreie Lesevorgänge zu implementieren.

Wenn die Isolationsstufe RR ist:

• Schreibvorgang: Sperre auf Zeilenebene hinzufügen. Nach dem Start der Transaktion wird ein Änderungsdatensatz in das UNDO-Protokoll geschrieben und die ausgeblendete Spalte DATA_POLL_PTR in der Datenzeile speichert einen Zeiger auf den UNDO-Datensatz der Zeile.

• Lesevorgang: Keine Verriegelung. Wenn die Zeile beim Lesen durch andere Transaktionen gesperrt ist, folgen Sie dem ausgeblendeten Spaltenzeiger DATA_POLL_PTR, um den vorherigen gültigen historischen Datensatz zu finden (gültiger Datensatz: Dieser Datensatz ist für die aktuelle Transaktion sichtbar und DELETE_BIT = 0).

Wie Sie aus dem oben Gesagten erkennen können: Tatsächlich sind die Vorgänge auf der RC- und RR-Ebene grundsätzlich gleich, der Unterschied liegt jedoch in der Sichtbarkeit des Zeilendatensatzes für aktuelle Transaktion (Sichtbarkeit: d. h. welche Versionszeilendatensätze für diese Transaktion sichtbar sind). Die Sichtbarkeit der Daten auf RC-Ebene ist die neueste Datenaufzeichnung, und die grundlegende Sichtbarkeit der Daten auf RR ist die Datenaufzeichnung zu Beginn der Transaktion.

(1) Implementierung der Sichtbarkeit von Zeilendatensätzen (read_view)

In innodb wird beim Erstellen einer Transaktion die Liste der aktiven Transaktionen im aktuellen System erstellt. Erstellen Sie a copy (read_view), in dem Transaktionen gespeichert werden, die zu Beginn der aktuellen Transaktion noch nicht festgeschrieben wurden. Die Werte in diesen Transaktionen sind für die aktuelle Transaktion nicht sichtbar.

Es gibt zwei Schlüsselwerte up_limit_id in read_view (die Mindestversionsnummer der aktuellen nicht festgeschriebenen Transaktion beträgt -1, Transaktionen vor up_limit_id wurden übermittelt, Transaktionen nach up_limit_id können übermittelt werden, dürfen nicht übermittelt werden ) und low_limit_id (Die nächste Transaktions-ID, die vom aktuellen System noch nicht zugewiesen wurde, ist der Maximalwert der bisher aufgetretenen Transaktions-IDs + 1. Hinweis: low_limit_id ist nicht die ID der größten aktiven Transaktion.)

Hinweis: Derzeit befinden sich die Transaktion und die festgeschriebene Transaktion nicht in read_view.

(2) Unabhängig davon, ob es sich um RC-Ebene oder RR-Ebene handelt, ist die Logik zur Beurteilung der Sichtbarkeit von Zeilendatensätzen dieselbe.

Wenn die Transaktion den Zeilendatensatz rückgängig liest, wird die Versionsnummer (DB_TRX_ID) des Zeilendatensatzes mit read_view verglichen:

1. Wenn DB_TRX_ID kleiner als up_limit_id ist, bedeutet dies, dass Die Zeile Der Datensatz wurde vor Beginn der aktuellen Transaktion festgeschrieben und DELETE_BIT=0, dann ist der Zeilendatensatz für die aktuelle Transaktion sichtbar.

2. Wenn DB_TRX_ID größer als low_limit_id ist, bedeutet dies, dass die Transaktion, in der die Zeile aufgezeichnet wird, nach der Erstellung dieser Transaktion gestartet wurde, sodass der aktuelle Wert des Zeilendatensatzes nicht sichtbar ist.

3. Wenn up_limit_id<= low_limit_id, ist DB_TRX_ID in der aktiven Transaktionskette. Wenn nicht, ist es sichtbar.

4. Wenn die oben genannten Urteile nicht sichtbar sind, lesen Sie den Datensatz der vorherigen Zeile im Rückgängigmachen und fahren Sie mit der Beurteilung fort.

Der Unterschied zwischen Snapshots auf Anweisungsebene auf RC-Ebene und Snapshots auf Transaktionsebene auf RR-Ebene wird tatsächlich durch den Zeitpunkt der read_view-Generierung erkannt.

Beim Ausführen einer Anweisung auf RC-Ebene wird zuerst die ursprüngliche read_view geschlossen und eine neue read_view neu generiert. Die read_view auf RR-Ebene wird nur zu Beginn der Transaktion erstellt. Daher erhält die RU-Ebene jedes Mal die neuesten Daten, während die RR-Ebene die Daten zu Beginn der Transaktion erhält.

(3) Es ist erwähnenswert: Im obigen Sichtbarkeitsurteil gibt es, obwohl die Logik dieselbe ist, Unterschiede in der praktischen Bedeutung:

im zweiten Schritt: Für die RC-Ebene ist low_limit_id die maximale Transaktions-ID + 1, die bei der Ausführung der Anweisung aufgetreten ist. Es kann davon ausgegangen werden, dass es bei der Ausführung der Anweisung keine Transaktion gibt, die größer als low_limit_id ist, also keine Transaktionen, die größer als low_limit_id sind Sichtbar.

Für die RR-Ebene ist low_limit_id die größte Transaktion, die zu Beginn der aktuellen Transaktion stattgefunden hat + 1 (sie kann auch als ID der aktuellen Transaktion + 1 betrachtet werden, denn wenn die aktuelle Transaktion stattfindet erstellt, die ID der aktuellen Transaktion ist die größte), Transaktionen größer als low_limit_id werden nach dem Start der Transaktion erstellt, sodass sie für die RR-Ebene nicht sichtbar sind.

Im dritten Schritt ist für die RC-Ebene RC sichtbar, solange DB_TRX_ID nicht in der aktiven verknüpften Liste enthalten ist, unabhängig davon, ob DB_TRX_ID größer als die Transaktions-ID ist.

Da low_limit_id die aktuelle Transaktions-ID + 1 ist, kann für die RR-Ebene davon ausgegangen werden, dass Transaktionen, die kleiner als low_limit_id sind, vor der Erstellung der aktuellen Transaktion angezeigt werden. Sie müssen also nur beurteilen, ob DB_TRX_ID vorhanden ist Aktive verknüpfte Liste.

Serialisierbar: Sowohl Lesen als auch Schreiben sind gesperrt

Das obige ist der detaillierte Inhalt vonWie wird die Isolationsstufe von MySQL implementiert?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!