Detaillierte Erläuterung der MySQL-Datenbankisolationsebene und des MVCC

MySQL ist eine der am häufigsten verwendeten Datenbanken in unserer täglichen Produktion und beim Lernen. Lassen Sie uns heute über die Isolationsebenen in MySQL (oder anderen ähnlichen Datenbanken) und die zur Verbesserung der Effizienz verwendete Multi-Version Concurrency Control (MVCC) sprechen.

1. Isolationsstufe

Zuerst müssen wir ein Konzept erwähnen: Transaktion. Was ist eine Transaktion? Eine Transaktion ist eine Sammlung einer Reihe von Operationsanweisungen, die eine grundlegende Operation abschließen. Wenn ich beispielsweise 200 Yuan von Konto A auf Konto B überweisen möchte, könnte ich Folgendes tun:
a. Überprüfen Sie, ob der Kontostand auf Konto A über 200 Yuan liegt.
b. Reduzieren Sie den Saldo auf Konto A um 200 RMB.
c. Fügen Sie dem Saldo auf Konto B 200 RMB hinzu.
Wir werden die drei oben genannten Vorgänge abc zu einer Transaktion kombinieren.
An dieser Stelle werden wir feststellen, dass eine Transaktion, über die wir sprechen, aus mehreren Anweisungen bestehen kann und Transaktionen atomar sind, d. h. die Ausführung einer Transaktion kann nicht unterbrochen werden. Dies wirft eine Frage auf: Wenn während der Ausführung dieser drei Schritte eine weitere Anweisung eingefügt wird, wirkt sich dies auf das Ergebnis aus, da die Atomizität der Transaktion zu diesem Zeitpunkt zerstört wird. Diese Art der Einfügung kommt in einer parallelen Umgebung sehr häufig vor. Daher müssen wir (oder die Datenbank-Engine) eine Transaktion während ihrer Ausführung „schützen“, das heißt, sicherstellen, dass Anweisungen aus anderen externen Transaktionen nicht willkürlich in die ausgeführten Transaktionsanweisungen eingefügt werden können, um die normale Ausführung der Transaktion sicherzustellen. Zu diesem Zeitpunkt fällt es uns leicht, an die Methode „Sperren“ zu denken. Dies ist eigentlich eine sehr allgemeine Aussage, denn obwohl das Sperren die normale Ausführung von Transaktionen sicherstellen kann, bringt es viel zusätzlichen Aufwand mit sich. Daher hat die Wahl der richtigen Sperrmethode zum richtigen Zeitpunkt einen großen Einfluss auf die Sucheffizienz. Die Strenge der „Sperre“ bestimmt die verschiedenen Isolationsstufen.

LESEN SIE UNVERBINDLICH

Auf dieser Isolationsebene wird das Lesen von Daten in keiner Weise beeinträchtigt. Das heißt, Sie können sogar Daten lesen, die gerade durch andere Transaktionen geändert werden, und Sie können sie jederzeit lesen und ändern. Dies hat sicherlich wenig Mehraufwand, kann aber viele Probleme verursachen, wie zum Beispiel „Dirty Reads“. Das heißt, dass Daten gelesen werden, die geändert, aber noch nicht übermittelt wurden, was zu Lesefehlern führt. In Bezug auf die Leistung ist READ UNCOMMITED nicht viel besser als andere Ebenen, bringt jedoch viele lästige Probleme mit sich, sodass es in der Praxis selten verwendet wird.

READ COMMITED (Read Committed/nicht wiederholbares Lesen)

Diese Ebene fügt einige Bestimmungen basierend auf READ UNCOMMITED hinzu und ist die Standardisolationsebene für einige Datenbanken. Der Unterschied zu READ UNCOMMITED besteht darin, dass beim Lesen nur die festgeschriebenen Daten gelesen werden dürfen. Beispielsweise ist der Wert von Daten a nach der letzten Übermittlung 1. Zu diesem Zeitpunkt kommt ein Thread herein, um a zu ändern, und ändert a in 2, aber die Transaktion (COMMIT) wird zu diesem Zeitpunkt nicht festgeschrieben. In diesem Fall ist der Wert eines Lesevorgangs auf der Ebene READ UNCOMMITED der aktuelle Wert 2, aber der auf der Ebene READ COMMITED gelesene Wert ist immer noch der Wert nach der letzten Übermittlung, d. h. a ist 1. Der Wert von a muss gelesen werden, nachdem der Änderungsthread den Wert von a in 2 geändert hat und die Transaktion festgeschrieben wurde, damit er 2 ist. Das Problem, das diese Ebene mit sich bringt, ist das nicht wiederholbare Lesen. Das heißt, der beim letzten Mal gelesene Wert von a war 1, aber als der Änderungsthread die Transaktion festschrieb, änderte sich der Wert von a auf 2 und der zu diesem Zeitpunkt gelesene Wert war 2, d. h. die durch zweimaliges Ausführen desselben Lesevorgangs erhaltenen Werte sind unterschiedlich.
Der Unterschied zwischen nicht wiederholbarem Lesen und Dirty Read besteht darin, dass Dirty Read eine Transaktion ist, bei der Daten während der Ausführung einer anderen, noch nicht abgeschlossenen Transaktion gelesen werden, während nicht wiederholbares Lesen vorliegt, wenn eine andere Transaktion die Daten festschreibt und ändert, die während der Ausführung einer Transaktion von der aktuellen Transaktion gelesen werden.

WIEDERHOLTES LESEN

REPEATED READ fügt einige restriktive Regeln basierend auf READ COMMITED hinzu und ist auch die Standardisolationsebene der MySQL-Datenbank. Einfach ausgedrückt ist es anderen Transaktionen untersagt, die entsprechenden Daten während der Ausführung einer Transaktion zu ändern. Dadurch wird sichergestellt, dass die während der Ausführung einer Transaktion abgefragten Daten konsistent sind, wodurch die Probleme von Dirty Reads und nicht wiederholbaren Lesevorgängen gelöst werden. Es bringt jedoch ein neues Problem mit sich, nämlich „Phantom-Lesevorgänge“.
„Phantomlesen“ bedeutet, dass, obwohl die Änderung der entsprechenden Daten während der Ausführung einer Transaktion verboten ist, andere Transaktionen dennoch Daten einfügen können. Zu diesem Zeitpunkt wird die erste Transaktion feststellen, dass einige zusätzliche Daten „unerklärlicherweise“ erscheinen, als ob eine Illusion aufgetreten wäre. Sowohl Phantom-Lesevorgänge als auch nicht wiederholbare Lesevorgänge lesen eine andere festgeschriebene Transaktion (was sich von Dirty Reads unterscheidet). Der Unterschied besteht darin, dass nicht wiederholbare Lesevorgänge dasselbe Datenelement abfragen, während Phantom-Lesevorgänge einen Datenstapel als Ganzes abfragen (z. B. die Anzahl der Daten).

SERIALISIERBAR

Dies ist die strengste Isolationsstufe. Es vermeidet das Problem von Phantomlesevorgängen, indem es die serielle Ausführung von Transaktionen erzwingt. Diese Isolationsebene ist jedoch sehr teuer und wird nicht oft verwendet.

Die Beziehung zwischen verschiedenen Isolationsebenen und möglichen Problemen ist wie folgt:

MVCC

Stellen Sie sich vor, dass bei jeder SQL-Operation eine Sperre auf Zeilenebene hinzugefügt werden muss, um Datenkonsistenz und -genauigkeit sicherzustellen. Dies ist zwar sehr zuverlässig, aber der daraus resultierende Systemaufwand und die verringerte Sucheffizienz sind ebenfalls sehr offensichtlich. Daher wurde MVCC entwickelt, um diesen Widerspruch aufzulösen.
Zunächst speichert MVCC hinter jeder Zeile in der Tabelle zwei versteckte Spalten: eine zum Speichern der Erstellungszeit der Zeile und die andere zum Speichern der Ablaufzeit (Löschzeit) der Zeile. Bei diesem Zeitwert handelt es sich nicht um die Echtzeit, sondern um eine Systemversionsnummer. Als Transaktionsversionsnummer wird dabei die Systemversionsnummer zu Beginn der Transaktion verwendet und mit der Versionsnummer jeder abgefragten Datensatzzeile verglichen.

• EINFÜGEN: Speichert die aktuelle Systemversionsnummer als Zeilenversionsnummer für jede neu eingefügte Zeile.
• LÖSCHEN: Speichert die aktuelle Systemversionsnummer als Zeilenlöschversionsnummer für jede gelöschte Zeile.
• UPDATE: Unter Update versteht man eigentlich den Vorgang des Einfügens neuer Daten und Löschens der Originaldaten, also das Speichern der aktuellen Systemversionsnummer als Zeilenversionsnummer für die neu eingefügten Daten und das Speichern der aktuellen Systemversionsnummer als Löschversionsnummer für die gelöschten Daten.
• SELECT: Abfrage nur von Zeilen, die die folgenden Bedingungen erfüllen:

a. Die Zeilenversionsnummer ist kleiner oder gleich der Transaktionsversionsnummer
b. Die Löschversionsnummer ist nicht definiert oder größer als die Transaktionsversionsnummer

Nach dem Speichern dieser beiden Versionsnummern können die meisten Vorgänge ohne Sperren korrekt ausgeführt werden, wodurch Leistung und Effizienz gewährleistet werden.
Es ist erwähnenswert, dass MVCC nur auf zwei Isolationsebenen funktioniert: READ COMMITED und REPEATABLE READ.

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