MySQL Series 10 MySQL-Transaktionsisolierung zur Implementierung der Parallelitätskontrolle

1. Gleichzeitige Zugriffskontrolle

Die implementierte Technologie zur gleichzeitigen Zugangskontrolle basiert auf Schlössern.

Sperren werden in Sperren auf Tabellenebene und Sperren auf Zeilenebene unterteilt. Die MyISAM-Speicher-Engine unterstützt keine Sperren auf Zeilenebene; InnoDB unterstützt Sperren auf Tabellenebene und Sperren auf Zeilenebene.

Sperren werden in Lesesperren und Schreibsperren eingeteilt. Lesesperren werden auch als gemeinsam genutzte Sperren bezeichnet. Wenn eine Lesesperre hinzugefügt wird, können andere Personen lesen. Schreibsperren werden auch als exklusive Sperren oder exklusive Sperren bezeichnet. Eine Schreibsperre blockiert andere Lese- und Schreibvorgänge.

Sperren werden in implizite und explizite Sperren unterteilt. Implizite Sperren werden von der Speicher-Engine verwaltet, während explizite Sperren manuell von Benutzern hinzugefügt werden.

Sperrstrategie: Ein Balancemechanismus zwischen Sperrgranularität und Datensicherheit.

So verwenden Sie explizite Sperren: LOCK TABLES tbl_name READ|WRITE

MariaDB [Schule]> LOCK TABLES students READ; #Lesesperre hinzufügen

MariaDB [Schule]> TABELLEN UNLOCK; #Unlock

Lesesperre: Niemand kann schreiben

Schreibsperre: Sie können lesen und schreiben, andere können jedoch nicht lesen und schreiben

FLUSH TABLES tb_name : Schließe die geöffnete Tabelle (lösche den Abfragecache), füge normalerweise vor dem Backup eine globale Lesesperre hinzu

SELECT-Klausel [FOR UPDATE | LOCK IN SHARE MODE] fügt Schreib- oder Lesesperren während der Abfrage hinzu

2. Transaktionen

Eine Reihe atomarer SQL-Anweisungen oder eine unabhängige Arbeitseinheit

1. Transaktionen folgen dem ACID-Prinzip:

• A: Atomarität; alle Vorgänge in der gesamten Transaktion werden entweder erfolgreich ausgeführt oder nach allen Fehlern zurückgesetzt.
• C: Konsistenz; die Datenbank wechselt immer von einem konsistenten Zustand in einen anderen
• I: Isolation; Operationen, die von einer Transaktion ausgeführt werden, können von anderen Transaktionen nicht gesehen werden, bevor sie festgeschrieben werden; es gibt mehrere Isolationsebenen, um Parallelität zu erreichen
• D: Dauerhaftigkeit; sobald eine Transaktion ausgeführt wurde, werden die vorgenommenen Änderungen dauerhaft in der Datenbank gespeichert.

2. Transaktionslebenszyklus

Explizite Transaktionen: Geben Sie den Beginn einer Transaktion eindeutig an

Implizite Transaktion: Die Standardeinstellung ist eine implizite Transaktion, die direkt nach der Ausführung jeder Anweisung festgeschrieben wird.

autocommit = {OFF|ON} schaltet Autocommit ein oder aus. Es wird empfohlen, Transaktionen explizit anzufordern und festzuschreiben, anstatt die Funktion „autocommit“ zu verwenden.

Eine Transaktion starten: START TRANSACTION;

Tag einfügen: ROLLBACK TO ##;

Rollback zum angegebenen Tag: ROLLBACK TO ##;

Alles rückgängig machen: ROLLBACK;

Transaktion festschreiben: COMMIT；

Tag löschen: RELEASE SAVEPOINT;

MariaDB [Schule]> START TRANSACTION; #Geben Sie explizit an, dass eine Transaktion gestartet werden sollMariaDB [Schule]> INSERT students(StuID,Name,Age,Gender) VALUES (26,'Tom',22,'M'); #Fügen Sie einen Datensatz hinzuMariaDB [Schule]> SAVEPOINT sp26; #Fügen Sie eine Beschriftung einMariaDB [Schule]> INSERT students(StuID,Name,Age,Gender) VALUES (27,'Maria',12,'F'); #Fügen Sie einen weiteren Datensatz hinzuMariaDB [Schule]> SELECT * FROM students WHERE stuid IN (26,27); #Überprüfen Sie und Sie können die gerade eingefügten Daten sehen+-------+-------+-----+--------+---------+-----------+
| StuID | Name | Alter | Geschlecht | KlassenID | LehrerID |
+-------+-------+-----+--------+---------+-----------+
| 26 | Tom | 22 | M | NULL | NULL |
| 27 | Maria | 12 | F | NULL | NULL |
+-------+-------+-----+--------+---------+-----------+
MariaDB [Schule]> ROLLBACK TO sp26; #Auf den Zustand vor dem Tag sp26 zurücksetzen MariaDB [Schule]> SELECT * FROM students WHERE stuid IN (26,27); #Überprüfen, Marias Informationen wurden zurückgezogen+-------+------+-----+--------+---------+-----------+
| StuID | Name | Alter | Geschlecht | KlassenID | LehrerID |
+-------+------+-----+--------+---------+-----------+
| 26 | Tom | 22 | M | NULL | NULL |
+-------+------+-----+--------+---------+-----------+
MariaDB [Schule]> COMMIT; #Transaktion festschreiben MariaDB [Schule]> SELECT * FROM students WHERE stuid IN (26,27); #Endgültige Daten+-------+------+-----+--------+---------+-----------+
| StuID | Name | Alter | Geschlecht | KlassenID | LehrerID |
+-------+------+-----+--------+---------+-----------+
| 26 | Tom | 22 | M | NULL | NULL |
+-------+------+-----+--------+---------+-----------+

3. Transaktionsisolationsebene

• READ UNCOMMITTED Andere Transaktionen können nicht festgeschriebene schmutzige Daten sehen, was zu schmutzigen Lesevorgängen führt
• READ COMMITTED Nachdem die Transaktion festgeschrieben wurde, können andere Transaktionen die geänderten Daten sehen. Die jedes Mal gelesenen Daten können inkonsistent sein und können nicht wiederholt gelesen werden.
• WIEDERHOLBARES LESEN Wiederholbares Lesen, die jedes Mal angezeigten Daten sind konsistent, die neuesten Daten können nach der Änderung der Daten nicht angezeigt werden und es erfolgt ein Phantomlesen (Standardeinstellung)
• FESTLEGEN Nicht festgeschriebene Lesetransaktionen blockieren Änderungstransaktionen, serielle Ausführung, schlechte Parallelität

MVCC: Multi-Version Concurrency Control, bezogen auf die Transaktionsebene

Ändern Sie die Transaktionsisolationsebene: Die Servervariable tx_isolation gibt an, der Standardwert ist REPEATABLE-READ, kann auf den Ebenen GLOBAL und SESSION festgelegt werden

tx_isolation

• Beschreibung: Die Transaktionsisolationsebene. Siehe auch SET TRANSACTION ISOLATION LEVEL.
• Befehlszeile: --transaction-isolation=name
• Umfang: Global, Sitzung
• Dynamisch: Ja
• Typ: Aufzählung
• Standardwert: REPEATABLE-READ
• Gültige Werte: READ-UNCOMMITTED , READ-COMMITTED , REPEATABLE-READ , SERIALIZABLE

MariaDB [Schule]> SELECT @@tx_isolation; #Standard ist wiederholbare Leseebene+-----------------+
| @@tx_isolation |
+-----------------+
| WIEDERHOLBARES LESEN |
+-----------------+
MariaDB [Schule]> SET tx_isolation='READ-UNCOMMITTED';
MariaDB [Schule]> set tx_isolation='READ-COMMITTED';
MariaDB [Schule]> set tx_isolation='REPEATABLE-READ';
MariaDB [Schule]> set tx_isolation='SERIALIZABLE';

4. Sackgasse

​Zwei oder mehr Transaktionen belegen dieselbe Ressource und fordern die Sperrung der von den anderen Transaktionen belegten Ressource an, was zu einem Deadlock führt.

Wenn Transaktion A die dritte Zeile der Tabelle t1 ändert und Transaktion B die zweite Zeile der Tabelle t2 ändert, wird Transaktion A blockiert, wenn sie die zweite Zeile der Tabelle t2 ändert. Dann wird Transaktion B blockiert, wenn sie die dritte Zeile der Tabelle t1 ändert, und es kommt zu einem Deadlock.

Zwei Transaktionen versuchen gleichzeitig, die geänderten Tabellen der jeweils anderen zu ändern, und blockieren sich dabei gegenseitig. Das System erkennt den Deadlock und opfert automatisch eine kostengünstige Transaktion, um den Deadlock aufzulösen.

FEHLER 1213 (40001): Beim Versuch, eine Sperre zu erhalten, wurde ein Deadlock festgestellt. Versuchen Sie, die Transaktion neu zu starten.

Zeigen Sie die Prozessliste an: MariaDB [school]> SHOW PROCESSLIST;

Beenden Sie den Prozess: MariaDB [school]> KILL 5;

Damit ist der Artikel zu MySQL Serie 10: MySQL-Transaktionsisolierung zur Implementierung der Parallelitätskontrolle abgeschlossen. Weitere Informationen zur MySQL-Parallelitätskontrolle finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!

Damit ist der Artikel zu MySQL Serie 10: MySQL-Transaktionsisolierung zur Implementierung der Parallelitätskontrolle abgeschlossen. Weitere Informationen zur MySQL-Parallelitätskontrolle finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!