Erläuterung der MySQL-Transaktionsauswahl für die Aktualisierung und Datenkonsistenzverarbeitung

Transaktionen in MySQL werden standardmäßig automatisch festgeschrieben, d. h. autocommit = 1;

Dies kann jedoch in manchen Situationen zu Problemen führen: zum Beispiel:

Wenn Sie 1000 Datensätze auf einmal einfügen möchten, führt MySQL 1000 Commits durch.

Wenn wir Autocommit ausschalten [Autocommit = 0] und es über das Programm steuern, ist nur ein Commit erforderlich, was die Eigenschaften der Transaktion besser widerspiegeln kann!

Für Operationen die numerische Werte erfordern, wie Betrag, Anzahl usw.!

Denken Sie an ein Prinzip: Erst sperren, dann beurteilen und dann aktualisieren

In MySQL InnoDB ist die Standard-Transaction-Isolationsebene REPEATABLE READ (wieder lesbar).

Es gibt zwei Haupttypen von Lesesperren in SELECT:

• AUSWÄHLEN ... SPERREN IM TEILEMODUS
• AUSWÄHLEN ... ZUM UPDATE

Wenn während einer Transaktion eine Auswahl aus derselben Datentabelle getroffen wird, müssen beide Methoden vor der Ausführung warten, bis andere Transaktionsdaten festgeschrieben sind.

Der Hauptunterschied besteht darin, dass LOCK IN SHARE MODE leicht einen Deadlock verursachen kann, wenn eine Transaktion dasselbe Formular aktualisieren möchte.

Einfach ausgedrückt: Wenn Sie nach SELECT dieselbe Tabelle AKTUALISIEREN möchten, verwenden Sie am besten SELECT ... UPDATE.

Zum Beispiel:

Angenommen, im Produktformular „Produkte“ ist eine Menge vorhanden, um die Produktmenge zu speichern. Bevor eine Bestellung aufgegeben wird, muss zunächst ermittelt werden, ob die Produktmenge ausreichend ist (Menge > 0), und dann die Menge auf 1 aktualisiert werden. Der Code lautet wie folgt:

WÄHLE Menge AUS Produkten, WO ID=3; AKTUALISIERE Produkte, SETZE Menge = 1, WO ID=3;

Warum ist es unsicher?

In einigen wenigen Fällen mag es kein Problem geben, aber bei Zugriffen auf große Datenmengen wird es definitiv Probleme geben. Wenn wir den Bestand nur dann reduzieren müssen, wenn die Menge > 0 ist, nehmen wir an, dass das Programm in der ersten SELECT-Zeile die Menge 2 liest. Es scheint, dass die Zahl korrekt ist, aber wenn MySQL gerade UPDATE durchführt, hat möglicherweise jemand den Bestand bereits auf 0 reduziert, aber das Programm weiß davon nichts und setzt das UPDATE ohne Fehler fort. Daher muss ein Transaktionsmechanismus verwendet werden, um sicherzustellen, dass die gelesenen und übermittelten Daten korrekt sind.

Damit wir es in MySQL wie folgt testen können, lautet der Code wie folgt:

SETZE AUTOCOMMIT=0; BEGINNE MIT DER ARBEIT; WÄHLE die Menge aus den Produkten, wobei ID=3 für die Aktualisierung ist;

Zu diesem Zeitpunkt SELECT * FROM products WHERE id=3 FOR UPDATE . Dadurch wird sichergestellt, dass die von anderen Transaktionen gelesene Mengennummer korrekt ist.

UPDATE-Produkte SETZEN Menge = '1' WHERE id=3; COMMIT WORK;

Commit schreibt in die Datenbank und entsperrt Produkte.

• Hinweis 1: BEGIN/COMMIT sind die Start- und Endpunkte einer Transaktion. Sie können zwei oder mehr MySQL-Befehlsfenster verwenden, um den Sperrstatus interaktiv zu beobachten.
• Hinweis 2: Während einer Transaktion wartet nur SELECT ... FOR UPDATE oder LOCK IN SHARE MODE für dieselben Daten, bis andere Transaktionen beendet sind, bevor sie ausgeführt werden. Normales SELECT ... ist hiervon nicht betroffen.
• Hinweis 3: Da InnoDB standardmäßig auf Zeilensperre eingestellt ist, lesen Sie bitte diesen Artikel zum Sperren von Datenspalten.
• Hinweis 4: Versuchen Sie, den Befehl LOCK TABLES nicht für InnoDB-Tabellen zu verwenden. Wenn Sie ihn verwenden müssen, lesen Sie bitte zuerst die offiziellen Anweisungen zur Verwendung von LOCK TABLES mit InnoDB, um häufige Deadlocks im System zu vermeiden.

MySQL SELECT ... FOR UPDATE Zeilensperre und Tabellensperre

Die Verwendung von SELECT ... FOR UPDATE wurde oben vorgestellt, Sie müssen jedoch bei der Beurteilung gesperrter Daten aufpassen. Da InnoDB standardmäßig eine Zeilensperre verwendet, führt MySQL nur dann eine Zeilensperre aus (sperrt nur die ausgewählten Daten), wenn der Primärschlüssel „explizit“ angegeben ist. Andernfalls führt MySQL eine Tabellensperre aus (sperrt die gesamte Datentabelle).

Zum Beispiel:

Angenommen, es gibt ein Formular „Produkte“ mit zwei Feldern „ID“ und „Name“, wobei die „ID“ der Primärschlüssel ist.

Beispiel 1: (Geben Sie den Primärschlüssel explizit an und lassen Sie diese Daten zeilensperren)

Wählen Sie * aus Produkten, wobei id = "3" für Update ist.

Beispiel 2: (kein Primärschlüssel, Tabellensperre)

SELECT * FROM Produkte WHERE Name='Maus' FOR UPDATE;

Beispiel 3: (Primärschlüssel ist unklar, Tabellensperre)

Wählen Sie * aus Produkten, wobei ID<>'3' für Update ist.

Beispiel 4: (Unklarer Primärschlüssel, Tabellensperre)

Wählen Sie * aus Produkten, wobei die ID wie „3“ für das Update lautet.

Optimistische und pessimistische Sperrstrategien

Pessimistische Sperre: sperrt die Zeilen beim Lesen von Daten, und andere Aktualisierungen dieser Zeilen müssen warten, bis die pessimistische Sperre endet, bevor sie fortfahren können.

Optimistische Sperre: Keine Sperre beim Lesen von Daten. Prüfen Sie beim Aktualisieren, ob die Daten aktualisiert wurden. Wenn ja, brechen Sie das aktuelle Update ab. Im Allgemeinen wählen wir eine optimistische Sperre, wenn die Wartezeit einer pessimistischen Sperre zu lang und inakzeptabel ist.

Zusammenfassen

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM. Wenn Sie mehr darüber erfahren möchten, schauen Sie sich bitte die folgenden Links an