[MySQL] Parallelitätskontrolle für mehrere Versionen

Die Implementierung der meisten Transaktionsspeicher-Engines in MySQL ist keine einfache Sperre auf Zeilenebene. Basierend auf der Überlegung, die Parallelitätsleistung zu verbessern, implementieren sie im Allgemeinen gleichzeitig die Multiversions-Parallelitätskontrolle (MVCC). Nicht nur MySQL, sondern auch andere Datenbanksysteme wie Oracle und PostgreSQL implementieren MVCC, ihre Implementierungsmechanismen sind jedoch unterschiedlich, da es keinen einheitlichen Standard für MVCC gibt.

Sie können sich MVCC als eine Variante des Sperrens auf Zeilenebene vorstellen, aber es vermeidet in vielen Fällen Sperrvorgänge, sodass der Overhead geringer ist. Obwohl die Implementierungsmechanismen unterschiedlich sind, implementieren die meisten von ihnen nicht blockierende Lesevorgänge, und Schreibvorgänge sperren nur die erforderlichen Zeilen.

MVCC wird implementiert, indem eine Momentaufnahme der Daten zu einem bestimmten Zeitpunkt gespeichert wird. Mit anderen Worten: Unabhängig davon, wie lange die Ausführung dauert, sind die von jeder Transaktion angezeigten Daten konsistent. Abhängig von der Zeit, zu der die Transaktion beginnt, können die Daten, die jede Transaktion zur gleichen Zeit in derselben Tabelle sieht, unterschiedlich sein.

Die MVCC-Implementierung verschiedener Speicher-Engines ist unterschiedlich, typischerweise optimistische Parallelitätskontrolle und pessimistische Parallelitätskontrolle. Im Folgenden veranschaulichen wir anhand einer vereinfachten Version des Verhaltens von InnoDB, wie MVCC funktioniert.

InnoDBs MVCC wird implementiert, indem zwei versteckte Spalten hinter jeder Datensatzzeile gespeichert werden. Von diesen beiden Spalten enthält eine die Erstellungszeit der Zeile und die andere die Ablaufzeit (oder Löschzeit) der Zeile. Gespeichert wird natürlich nicht der tatsächliche Zeitwert, sondern die Systemversionsnummer. Bei jedem Start einer neuen Transaktion wird die Systemversionsnummer automatisch erhöht. Angelegenheiten. Die Systemversionsnummer zu Beginn der Transaktion wird als Versionsnummer der Transaktion verwendet, die zum Vergleich mit der Versionsnummer jeder abgefragten Datensatzzeile verwendet wird. Werfen wir einen Blick darauf, wie MVCC unter der Isolationsstufe REPEATABLE READ funktioniert.

SELECT

InnoDB prüft jede Datensatzzeile anhand der folgenden zwei Bedingungen:

• InnoDB sucht nur nach Datenzeilen, deren Versionsnummer früher ist als die aktuelle Transaktionsversion (d. h. die Systemversionsnummer der Zeile ist kleiner oder gleich der Transaktion). Dadurch wird sichergestellt, dass die von der Transaktion gelesenen Zeilen entweder bereits vor dem Start der Transaktion vorhanden sind oder von eingefügt oder geändert wurden die Transaktion selbst. Die gelöschte Version der Zeile

• ist entweder undefiniert oder größer als die aktuelle Transaktionsversionsnummer. Dadurch wird sichergestellt, dass die von der Transaktion gelesenen Zeilen nicht vor dem Start der Transaktion gelöscht wurden.

Nur ​​Datensätze, die die beiden oben genannten Bedingungen erfüllen, können als Abfrageergebnisse zurückgegeben werden.

INSERT

InnoDB speichert die aktuelle Systemversionsnummer als Zeilenversionsnummer für jede eingefügte Zeile.

DELETE

InnoDB speichert die aktuelle Systemversionsnummer als Zeilenlöschungskennung für jede gelöschte Zeile.

UPDATE

InnoDB fügt eine neue Zeile mit Datensätzen ein, speichert die aktuelle Systemversionsnummer als Zeilenversionsnummer und speichert die aktuelle Systemversionsnummer in der ursprünglichen Zeile als Zeilenlöschungskennung.

Speichern Sie diese beiden zusätzlichen Systemversionsnummern, damit die meisten Datenlesevorgänge ohne Sperren durchgeführt werden können. Dieses Design macht den Datenlesevorgang sehr einfach, die Leistung ist sehr gut und es stellt außerdem sicher, dass nur Zeilen gelesen werden, die den Standards entsprechen. Die Nachteile bestehen darin, dass jede Zeile mit Datensätzen zusätzlichen Speicherplatz, mehr Überprüfung und einige zusätzliche Wartung erfordert.

MVCC funktioniert nur unter zwei Isolationsstufen: REPEATABLE READ und READ COMMITTED. Die anderen beiden Isolationsstufen sind nicht mit MVCC kompatibel, da READ UNCOMMITTED immer die neueste Datenzeile liest, nicht die Datenzeile, die der aktuellen Transaktionsversion entspricht. SERIALIZABLE sperrt alle gelesenen Zeilen.

Hinweis: MVCC hat keine formale Spezifikation, daher ist die Implementierung jeder Speicher-Engine und jedes Datenbanksystems unterschiedlich. Niemand kann sagen, dass andere Methoden falsch sind.

Die Implementierung der meisten Transaktionsspeicher-Engines in MySQL ist keine einfache Sperre auf Zeilenebene. Basierend auf der Überlegung, die Parallelitätsleistung zu verbessern, implementieren sie im Allgemeinen gleichzeitig die Multiversions-Parallelitätskontrolle (MVCC). Nicht nur MySQL, sondern auch andere Datenbanksysteme wie Oracle und PostgreSQL implementieren MVCC, ihre Implementierungsmechanismen sind jedoch unterschiedlich, da es keinen einheitlichen Standard für MVCC gibt.

Sie können sich MVCC als eine Variante des Sperrens auf Zeilenebene vorstellen, aber es vermeidet in vielen Fällen Sperrvorgänge, sodass der Overhead geringer ist. Obwohl die Implementierungsmechanismen unterschiedlich sind, implementieren die meisten von ihnen nicht blockierende Lesevorgänge, und Schreibvorgänge sperren nur die erforderlichen Zeilen.

MVCC wird implementiert, indem eine Momentaufnahme der Daten zu einem bestimmten Zeitpunkt gespeichert wird. Mit anderen Worten: Unabhängig davon, wie lange die Ausführung dauert, sind die von jeder Transaktion angezeigten Daten konsistent. Abhängig von der Zeit, zu der die Transaktion beginnt, können die Daten, die jede Transaktion zur gleichen Zeit in derselben Tabelle sieht, unterschiedlich sein.

Die MVCC-Implementierung verschiedener Speicher-Engines ist unterschiedlich, typischerweise optimistische Parallelitätskontrolle und pessimistische Parallelitätskontrolle. Im Folgenden veranschaulichen wir anhand einer vereinfachten Version des Verhaltens von InnoDB, wie MVCC funktioniert.

InnoDBs MVCC wird implementiert, indem zwei versteckte Spalten hinter jeder Datensatzzeile gespeichert werden. Von diesen beiden Spalten enthält eine die Erstellungszeit der Zeile und die andere die Ablaufzeit (oder Löschzeit) der Zeile. Gespeichert wird natürlich nicht der tatsächliche Zeitwert, sondern die Systemversionsnummer. Jedes Mal, wenn eine neue Transaktion gestartet wird, wird die Systemversionsnummer automatisch erhöht. Angelegenheiten. Die Systemversionsnummer zu Beginn der Transaktion wird als Versionsnummer der Transaktion verwendet, die zum Vergleich mit der Versionsnummer jeder abgefragten Datensatzzeile verwendet wird. Werfen wir einen Blick darauf, wie MVCC speziell unter der Isolationsstufe REPEATABLE READ funktioniert.

SELECT

InnoDB prüft jede Datensatzzeile gemäß den folgenden zwei Bedingungen:

• InnoDB sucht nur nach Datenzeilen, deren Versionsnummer früher ist als die aktuelle Transaktionsversion (d. h. die Systemversionsnummer der Zeile ist kleiner oder gleich der Transaktion). Dadurch wird sichergestellt, dass die von der Transaktion gelesenen Zeilen entweder bereits vor dem Start der Transaktion vorhanden sind oder von eingefügt oder geändert wurden die Transaktion selbst. Die gelöschte Version der Zeile

• ist entweder undefiniert oder größer als die aktuelle Transaktionsversionsnummer. Dadurch wird sichergestellt, dass die von der Transaktion gelesenen Zeilen nicht vor dem Start der Transaktion gelöscht wurden.

Nur ​​Datensätze, die die beiden oben genannten Bedingungen erfüllen, können als Abfrageergebnisse zurückgegeben werden.

INSERT

InnoDB speichert die aktuelle Systemversionsnummer als Zeilenversionsnummer für jede eingefügte Zeile.

DELETE

InnoDB speichert die aktuelle Systemversionsnummer als Zeilenlöschungskennung für jede gelöschte Zeile.

UPDATE

InnoDB fügt eine neue Zeile mit Datensätzen ein, speichert die aktuelle Systemversionsnummer als Zeilenversionsnummer und speichert die aktuelle Systemversionsnummer in der ursprünglichen Zeile als Zeilenlöschungskennung.

Speichern Sie diese beiden zusätzlichen Systemversionsnummern, damit die meisten Datenlesevorgänge ohne Sperren durchgeführt werden können. Dieses Design macht den Datenlesevorgang sehr einfach, die Leistung ist sehr gut und es stellt außerdem sicher, dass nur Zeilen gelesen werden, die den Standards entsprechen. Die Nachteile bestehen darin, dass jede Zeile mit Datensätzen zusätzlichen Speicherplatz, mehr Überprüfung und einige zusätzliche Wartung erfordert.

MVCC funktioniert nur unter zwei Isolationsstufen: REPEATABLE READ und READ COMMITTED. Die anderen beiden Isolationsstufen sind nicht mit MVCC kompatibel, da READ UNCOMMITTED immer die neueste Datenzeile liest, nicht die Datenzeile, die der aktuellen Transaktionsversion entspricht. SERIALIZABLE sperrt alle gelesenen Zeilen.

Hinweis: MVCC hat keine formale Spezifikation, daher ist die Implementierung jeder Speicher-Engine und jedes Datenbanksystems unterschiedlich. Niemand kann sagen, dass andere Methoden falsch sind.

Das Obige ist der Inhalt der Parallelitätskontrolle für mehrere Versionen von [MySQL] Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php.cn)!