MySQL-Methode zur Sperrensteuerung für Parallelität

Vorwort

Sperren können im Allgemeinen in optimistische und pessimistische Sperren unterteilt werden. Einfach ausgedrückt werden optimistische Sperren durch Versionsnummern gesteuert, während pessimistische Sperren durch Sperren gesteuert werden.

Nachfolgend sind die für die Tests zu verwendenden Daten aufgeführt.

# Fügen Sie eine Benutzertabelle hinzu CREATE TABLE `users` (
 `id` int(11) NICHT NULL AUTO_INCREMENT KOMMENTAR 'ID',
 `name` varchar(255) NICHT NULL KOMMENTAR 'Name',
 PRIMÄRSCHLÜSSEL (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
#3 Datensätze einfügen INSERT INTO `users` (`id`, `name`)
WERTE
 (1, 'Fliegendes Schwein vom Schneeberg'),
 (2, 'chenqionghe'),
 (3, 'cqh');

Die Abfrageergebnisse lauten wie folgt:

1. Optimistisches Sperren

Das Kernprinzip besteht darin, zur Steuerung ein Versionsfeld hinzuzufügen.
Wenn wir beispielsweise eine einzelne Zeile gleichzeitig aktualisieren möchten, wird nur ein Prozess erfolgreich aktualisiert, wie folgt

UPDATE users SET name="Benutzername" WHERE id=3
UPDATE Benutzer SET name="chenqionghe" WHERE id=3

Die beiden obigen SQL-Anweisungen werden letztendlich erfolgreich aktualisiert und das letzte Aktualisierungsergebnis wird das wichtigste sein.

Die Lösung besteht darin, ein Versionsfeld hinzuzufügen

Fügen Sie das Versionsfeld hinzu

ALTER TABLE-Benutzer ADD `Version` INT NOT NULL DEFAULT '0'

Die Lösung besteht darin, ein Versionsfeld hinzuzufügen, es bei jedem Update zur Where-Bedingung hinzuzufügen und es auch zu aktualisieren

UPDATE users SET name="Benutzername",version=version+1 WHERE id=3 AND version=0
UPDATE-Benutzer SET name="chenqionghe",version=version+1 WHERE id=3 AND version=0

Dieses Mal ist die Aktualisierung nur einmal erfolgreich. Wer den Datensatz zuerst erfasst, ist der Master, da sich die Versionsnummer nach der erfolgreichen Aktualisierung des aktuellen Prozesses geändert hat und der zweite Prozess diesen Datensatz nicht finden kann.
Dies ist der einfachste CAS-Mechanismus.

2. Pessimistische Sperre

Tatsächlich ähnelt es den Mutex- und RwMutex-Lesesperren in der Sprache Go

Lesesperre

Wird auch als gemeinsame Sperre oder S-Sperre bezeichnet. Wenn einer Datentabelle eine gemeinsame Sperre hinzugefügt wird, wechselt die Tabelle in den schreibgeschützten Modus.
Wir können die gesamte Tabelle sperren oder die gesamte Tabelle oder einige Zeilen wie folgt sperren

Vollständige Tabellensperre (LOCK TABLE-Tabelle READ)

Die Syntax lautet wie folgt

LOCK TABLE Tabelle READ
TABELLE ENTSPERREN;

Lassen Sie uns einen testen. Der erste Prozess wird ausgeführt

LOCK TABLE-Benutzer lesen; 

Der zweite Prozess führt einen normalen Lesevorgang aus

Wählen Sie * von Benutzern aus, wobei ID = 1; 

Sie können normal abfragen. Führen wir das Update noch einmal durch

UPDATE Benutzer SET name="chenqionghe" WHERE id=1 

Es gab eine Wartezeit.

Wir schalten den ersten Prozess frei

Betrachtet man den zweiten Prozess, wurde er erfolgreich aktualisiert

Zeilensperren (AUSWÄHLEN ... SPERREN IM FREIGABEMODUS)

BEGINNEN;
SELECT * FROM users WHERE id IN (1,2) LOCK IN SHARE MODE
BEGEHEN;

Muss bei Transaktionen verwendet werden. Nach dem Start von BEIN können gesperrte Zeilen nur extern abgefragt, aber nicht aktualisiert werden.

Lassen Sie es uns testen. Der erste Prozess wird ausgeführt

BEGINNEN;
SELECT * FROM users WHERE id IN (1,2) LOCK IN SHARE MODE 

Dabei werden die Zeilen mit der ID 1 und 2 gesperrt. Unser zweiter Prozess führt das Update durch

UPDATE users SET name="Benutzername" WHERE id=1

Wieder einmal gab es eine Wartezeit.
OK, jetzt committen wir die Transaktion des ersten Prozesses

BEGEHEN; 

Das zweite Prozessupdate verlief wie folgt erfolgreich:

Schreibsperre

Exklusive Sperre, exklusive Sperre, verstanden als Lesen und Schreiben sind nicht möglich, die Syntax ist wie folgt

Vollständige Tabellensperre (LOCK TABLE Tabelle WRITE)

LOCK TABLE-Benutzer schreiben;

Zu diesem Zeitpunkt wurde die gesamte Tabelle gesperrt. Verwenden wir einen anderen Prozess, um die Daten mit der ID 1 abzufragen.

SELECT * FROM Benutzer WHERE id=1 

Wie Sie sehen, hat die Abfrage bereits gewartet.
Lassen Sie uns den ersten Vorgang freischalten.

TABELLE ENTSPERREN 

Zu diesem Zeitpunkt ist der zweite Prozess sofort erfolgreich bei der Abfrage

Zeilensperren (SELECT ... FOR UPDATE)

Wenn wir Daten aktualisieren (INSERT, DELETE, UPDATE), verwendet die Datenbank automatisch eine exklusive Sperre, um zu verhindern, dass andere Transaktionen die Daten verarbeiten.

BEGINNEN;
SELECT * FROM users WHERE id IN (1,2) LOCK IN SHARE MODE
BEGEHEN;

Lassen Sie uns noch einmal testen. Der erste Prozess sperrt Datensätze mit den IDs 1 und 2.

BEGINNEN;
Wählen Sie * von Benutzern, wo ID in (1,2) für Update

Hinweis: Die Transaktion wird zu diesem Zeitpunkt nicht bestätigt.

Wir verwenden zunächst den zweiten Prozess, um den Datensatz mit der ID 3 (nicht gesperrt) zu aktualisieren.

UPDATE Benutzer SET name="chenqionghe" WHERE id=3 

Die Ausführung war erfolgreich.
Aktualisieren wir einen Datensatz mit der ID 1.

UPDATE Benutzer SET name="chenqionghe" WHERE id=1

Es ist eine Wartezeit aufgetreten, die darauf hinweist, dass es gesperrt wurde.
OK, senden wir die Transaktion des ersten Prozesses

BEGEHEN;

Schauen Sie sich den zweiten Prozess noch einmal an, er wurde erfolgreich aktualisiert

Einfach ausgedrückt: Optimistische Sperren verwenden Versionskontrolle, pessimistische Tabellensperren sind im Allgemeinen nicht erforderlich, Zeilenlesesperren verwenden LOCK IN SHARE MODE und Schreibsperren verwenden FRO UPDATE. So einfach ist das!

Oben sind die Details der Methode zum Sperren und Steuern der MySQL-Parallelität aufgeführt. Weitere Informationen zum Sperren und Steuern der MySQL-Parallelität finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!