Zusammenfassung der Verwendung pessimistischer Sperren in Laravel-Transaktionen

Laravel bietet eine bequeme und schnelle Möglichkeit, Datenbanktransaktionen zu verwenden. Ich bin auf mehrere Stellen gestoßen, die bei der Verwendung leicht verwechselt und in die Irre geführt werden können. Ich hoffe, dass einige Experten darauf hinweisen können, wo ich falsch liege

Laravel-Transaktionen sind in manuelle und automatische Methoden unterteilt. Wenn wir jedoch die von Laravel bereitgestellte Sperrtabellenmethode „sharedLock“ oder „lockForUpdate“ verwenden, wird empfohlen, die manuelle Übermittlung von Transaktionen zu verwenden, um unnötige Probleme und Fehler zu vermeiden, wie gezeigt unten:

Lassen Sie uns über die Unterschiede und Auswirkungen von sharedLock (gemeinsame Sperre) und lockForUpdate (pessimistische Sperre) sprechen

sharedLock (gemeinsame Sperre)

sharedLock entspricht der SQL-Anweisung *select fromtransaction_test where type = 1 lock in share mode;**

in einer Transaktion Es wird wirksam Nur wenn sharedLock verwendet wird und die Zeile, in der sich die Daten befinden, gesperrt wird. Zu diesem Zeitpunkt dürfen die gesperrten Daten nicht durch andere Vorgänge geändert werden, die gesperrten Daten haben jedoch keinen Einfluss auf den Abfragevorgang, sofern dies der Fall ist Eine normale Abfrage oder eine Abfrage in einem Transaktionsvorgang ist davon nicht betroffen. Die gesperrten Daten werden erst freigegeben, wenn die Transaktion festgeschrieben oder zurückgesetzt wird.

lockForUpdate (pessimistische Sperre)

lockForUpdate entspricht bei Verwendung der SQL-Anweisung *select fromtransaction_test where type = 1 for update;**

lockForUpdate wird nur in einer Transaktion wirksam. Bei Verwendung von lockForUpdate wird die Zeile, in der sich die Daten befinden, zu diesem Zeitpunkt gesperrt wartet auf die Ausführung der aktuellen Transaktion, es gibt jedoch keine Einschränkungen für nicht sperrende Tabellen und normale Abfragevorgänge. Betroffen sind nur die sperrenden Tabellenvorgänge, die Sie auch in der Transaktion ausführen.

In Kurz gesagt, unabhängig davon, ob es sich um eine gemeinsame Sperre oder eine pessimistische Sperre handelt, hat der betroffene Nur der in der Transaktion ausgeführte Tabellensperrvorgang keinen Einfluss auf normale Abfragevorgänge und nicht sperrende Tabellenvorgänge in der Transaktion.

Gleichzeitig Gleichzeitig ist zu beachten, dass MySQL, unabhängig davon, ob es sich um pessimistisches Sperren oder gemeinsames Sperren handelt, einen Index enthält und den Index als Grundlage für Abfragen oder Beurteilungen verwendet. MySQL verwendet Sperren auf Zeilenebene, um die zu ändernden Zeilen zu sperren. Andernfalls werden Tabellensperren verwendet, um die gesamte Tabelle zu sperren. Verwenden Sie daher unbedingt den Index, da dies sonst zu Problemen mit der hohen Parallelität führt

Das obige ist der detaillierte Inhalt vonZusammenfassung der Verwendung pessimistischer Sperren in Laravel-Transaktionen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!