Detaillierte Erläuterung der MySQL-Transaktionsisolationsebene und des MVCC

Transaktionsisolationsebene

Bei der gleichzeitigen Transaktionsausführung aufgetretene Probleme

• Schmutziges Schreiben
  
  • Wenn eine Transaktion Daten ändert, die bereits durch eine andere, nicht festgeschriebene Transaktion geändert wurden, bedeutet dies, dass ein „Dirty Write“ aufgetreten ist.
    
• Schmutzige Lektüre
  
  • Wenn eine Transaktion Daten liest, die von einer anderen, nicht festgeschriebenen Transaktion geändert wurden, bedeutet dies, dass ein Dirty Read aufgetreten ist.
    
• Nicht wiederholbares Lesen
  
  • Wenn eine Transaktion nur Daten lesen kann, die von einer anderen festgeschriebenen Transaktion geändert wurden, und die Transaktion jedes Mal, wenn andere Transaktionen die Daten ändern und festschreiben, den neuesten Wert abfragen kann, bedeutet dies, dass ein nicht wiederholbarer Lesevorgang aufgetreten ist.
    
• Phantom lesen
  
  • Wenn eine Transaktion zunächst einige Datensätze basierend auf bestimmten Bedingungen abfragt und dann eine andere Transaktion Datensätze, die diese Bedingungen erfüllen, in die Tabelle einfügt, kann die ursprüngliche Transaktion bei der erneuten Abfrage gemäß den Bedingungen auch die von der anderen Transaktion eingefügten Datensätze lesen, was bedeutet, dass ein Phantom-Lesevorgang aufgetreten ist.
  • Phantom-Lesevorgänge betonen, dass, wenn eine Transaktion Datensätze mehrfach unter derselben Bedingung liest, bei den späteren Lesevorgängen Datensätze gelesen werden, die zuvor nicht gelesen wurden.
  • Was ist mit der Situation, dass ein zuvor gelesener Datensatz später nicht mehr gelesen werden kann? Tatsächlich ist dies gleichbedeutend mit einem nicht wiederholbaren Lesevorgang, der für jeden Datensatz erfolgt. Phantom-Lesevorgänge betonen lediglich, dass Datensätze gelesen wurden, die bei vorherigen Lesevorgängen nicht erhalten wurden.
    

Vier Isolationsebenen im SQL-Standard

• READ UNCOMMITTED: Nicht festgeschriebenes Dirty Read, nicht wiederholbares Lesen und Phantomlesen treten auf
• READ COMMITTED: Read committed, nicht wiederholbares Lesen, Phantomlesen erfolgt
• REPEATBLE READ: Wiederholbares Lesen Phantomlesen erfolgt
• SERIALIZABLE: Serialisierbarkeit findet nicht statt
  

In MySQL werden vier Isolationsebenen unterstützt

• MySQL kann Phantomlesevorgänge auf der Isolationsebene REPEATABLE READ verhindern (wir erklären später, wie man Phantomlesevorgänge verhindert).
• Die Standardisolationsstufe von MySQL ist REPEATABLE READ
  

MVCC-Prinzip

Versionskette

Bei Tabellen, die die Speicher-Engine InnoDB verwenden, enthalten die Clustered-Index-Datensätze zwei notwendige ausgeblendete Spalten:

• trx_id: Jedes Mal, wenn eine Transaktion einen gruppierten Indexdatensatz ändert, wird die Transaktions-ID der Transaktion der ausgeblendeten Spalte trx_id zugewiesen.
• roll_pointer: Jedes Mal, wenn ein Clustered-Indexdatensatz geändert wird, wird die alte Version in das Rückgängig-Protokoll geschrieben. Anschließend entspricht diese ausgeblendete Spalte einem Zeiger, mit dem die Informationen vor der Änderung des Datensatzes gefunden werden können.
  

LesenAnzeigen

• Da Sie bei Transaktionen mit der Isolationsebene READ UNCIMMITTED Datensätze lesen können, die durch nicht festgeschriebene Transaktionen geändert wurden, können Sie einfach die neueste Version der Datensätze direkt lesen.
• Bei Transaktionen mit den Isolationsstufen READ COMMITTED und REPEATABLE READ muss sichergestellt werden, dass die von den festgeschriebenen Transaktionen geänderten Datensätze gelesen werden. Das heißt, wenn eine andere Transaktion die Datensätze geändert hat, aber noch nicht festgeschrieben wurde, kann die neueste Version der Datensätze nicht direkt gelesen werden. Kernproblem: Es muss ermittelt werden, welche Version in der Versionskette für die aktuelle Transaktion sichtbar ist. ReadView ist für diesen Zweck konzipiert
• readView enthält 4 wichtige Inhalte:
  • m_ids: Gibt die Transaktions-ID der aktiven Lese- und Schreibtransaktionen im aktuellen System an, wenn die ReadView generiert wird
  • min_trx_id: Gibt die kleinste Transaktions-ID unter den aktiven Lese- und 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 der nächsten Transaktion im System beim Generieren einer ReadView zugewiesen werden soll
  • creator_trx_id: gibt die Transaktions-ID der Transaktion an, die den ReadView generiert hat.
    
    • Wie bereits erwähnt, wird einer Transaktion nur dann eine Transaktions-ID zugewiesen, wenn Änderungen an Datensätzen in einer Tabelle vorgenommen werden (wenn INSERT-, DELETE- und UPDATE-Anweisungen ausgeführt werden). Andernfalls ist der Transaktions-ID-Wert in einer schreibgeschützten Transaktion standardmäßig 0.
• 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:
  • Wenn das trx_id-Attribut der aufgerufenen Version mit der creator_trx_id in ReadView identisch ist, bedeutet dies, dass die aktuelle Transaktion auf den Datensatz zugreift, den sie geändert hat, sodass die Version von der aktuellen Transaktion aufgerufen werden kann.
  • Wenn der aufgerufene Attributwert „trx_id“ kleiner als der Wert „min_trx_id“ in ReadView ist, bedeutet dies, dass die Transaktion, die diese Version generiert hat, festgeschrieben wurde, als die aktuelle Transaktion ReadView generierte. Auf diese Version kann daher von der aktuellen Transaktion zugegriffen werden.
  • Wenn der Attributwert „trx_id“ der aufgerufenen Version größer oder gleich dem Wert „max_trx_id“ in ReadView ist, bedeutet dies, dass die Transaktion, die diese Version generiert hat, geöffnet wurde, nachdem die aktuelle Transaktion ReadView generiert hat. Auf diese Version kann daher von der aktuellen Transaktion nicht zugegriffen werden.
  • Wenn der Attributwert trx_id der aufgerufenen Version zwischen min_trx_id und max_trx_id der ReadView liegt, muss ermittelt werden, ob der Attributwert trx_id in der m_ids-Liste enthalten ist. Wenn dies der Fall ist, bedeutet dies, dass die Transaktion, die die Version beim Erstellen der ReadView generiert hat, noch aktiv ist und auf die Version nicht zugegriffen werden kann. Wenn dies nicht der Fall ist, bedeutet dies, dass die Transaktion, die die Version beim Erstellen der ReadView generiert hat, festgeschrieben wurde und auf die Version zugegriffen werden kann.

Um es zusammenzufassen:

• Eine Transaktion auf der Isolationsebene READ COMMITTED generiert zu Beginn jeder Abfrage eine separate ReadView.
• REPEATABLE READ: Erzeugt beim ersten Einlesen der Daten einen ReadView, wodurch die Ergebnisse der beiden SELECT-Abfragen dupliziert werden.
  

MVCC-Zusammenfassung: Das sogenannte MVCC bezieht sich auf den Prozess des Zugriffs auf die Versionskette von Datensätzen bei der Ausführung gewöhnlicher SELECT-Operationen mit Transaktionen auf den Isolationsebenen READ COMMITTED und REPEATABLE READ. Dadurch können Lese-/Schreib- und Schreib-/Leseoperationen verschiedener Transaktionen gleichzeitig ausgeführt werden, was die Leistung verbessert.

So lösen Sie Phantom-Reads in MySQL auf RR-Ebene

1. Beim aktuellen Lesen wird die neueste Version gelesen und die Sperre des entsprechenden Datensatzes muss erworben werden, wie im folgenden SQL gezeigt

• auswählen ... im Freigabemodus sperren
• wählen Sie ... zum Aktualisieren
• aktualisieren, löschen, einfügen
  

Das Phantomlesen wird durch die nächste Taste erreicht.

2. Das Lesen von Snapshots wird durch MVCC gelöst

Oben finden Sie eine ausführliche Erläuterung der Isolationsstufe und des MVCC von MySQL-Transaktionen. Weitere Informationen zur Isolationsstufe und zum MVCC von MySQL-Transaktionen finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!