MySQL Advanced (4) MySQL Select

wählen Sie * für Aktualisierung

in MySQL Hinweis:

FOR UPDATE gilt nur für InnoDB und muss sich im Transaktionsblock (BEGIN/COMMIT) befinden, um wirksam zu werden.

Funktion

Sperren Sie das durch diese Anweisung ausgewählte Objekt. Dies verhindert Dateninkonsistenzen, die dadurch entstehen, dass diese Objekte nach der Auswahl an anderer Stelle geändert werden. Um sicherzustellen, dass Datensätze während der Ausführung von Statistiken (Abfragen) nicht von anderen Benutzern aktualisiert werden, kann

mithilfe der For-Update-Klausel gesperrt werden. Auf diese Weise können andere Benutzer diese Datensätze nicht aktualisieren, löschen oder sperren, bevor die Sperre aufgehoben wird.

Wählen Sie daptno aus dept Where deptno=25 Für die Aktualisierung
Wenn Sie FOR UPDATE verwenden, um die Tabelle zu sperren, müssen Sie commit verwenden, um die gesperrten Datensätze freizugeben.

Sperren sind in zwei Kategorien unterteilt: Sperrbereichsklausel und Sperrverhaltensklausel. Sperrbereichsklausel: Nach „select...for update“ können Sie die of-Klausel verwenden, um die Auswahl auszuwählen. Sperren durchführen Operationen an bestimmten Datentabellen. Standardmäßig bedeutet die Nichtverwendung der of-Klausel, dass alle Datentabellen in der select-Klausel gesperrt werden: Wenn wir die for update-Operation ausführen, unterscheidet sie sich stark von der gewöhnlichen select. Im Allgemeinen muss bei der Auswahl nicht berücksichtigt werden, ob die Daten gesperrt sind, sondern es wird höchstens die vorherige Version basierend auf der Funktion des konsistenten Lesens mehrerer Versionen gelesen.
Die Regel für die UPDATE-Anweisung sperrt die Tupel in den Abfrageergebnissen, bis diese Transaktion festgeschrieben wird.

Anwendungsszenarien

Wann müssen Sie also ein Update durchführen? Wenn Daten auf Unternehmensebene exklusiv sein müssen, können Sie die Verwendung von for update in Betracht ziehen. In Szenarien wie der Buchung von Bahntickets werden die verbleibenden Tickets auf dem Bildschirm angezeigt. Bei der tatsächlichen Ausstellung der Tickets müssen Sie erneut bestätigen, dass die Daten nicht von anderen Kunden geändert wurden. Daher können Sie während dieses Bestätigungsprozesses die Aktualisierung durchführen. Dies ist ein einheitliches Lösungsproblem und erfordert eine vorherige Vorbereitung.

Da InnoDB standardmäßig die Zeilensperre verwendet, führt MySQL die Zeilensperre nur aus, wenn der Primärschlüssel „explizit“ angegeben ist (nur der ausgewählte Schlüssel wird gesperrt). ) Datenbeispiel), andernfalls führt MySQL eine Tabellensperre aus (sperrt das gesamte Datenformular).

Beispiel 1

Lassen Sie mich einige Beispiele nennen:

select * from t for update 会等待行锁释放之后，返回查询结果。
select * from t for update nowait 不等待行锁释放，提示锁冲突，不返回结果
select * from t for update wait 5 等待5秒，若行锁仍未释放，则提示锁冲突，不返回结果
select * from t for update skip locked 查询返回查询结果，但忽略有行锁的记录

Die Syntax der SELECT...FOR UPDATE-Anweisung lautet wie folgt:
　

　SELECT ... FOR UPDATE [OF column_list][WAIT n|NOWAIT][SKIP LOCKED];

Wobei:
　OF-Klausel wird verwendet, um die zu aktualisierende Spalte anzugeben, d. h. um eine bestimmte Spalte in der Zeile zu sperren.
Die WAIT-Klausel gibt die Anzahl der Sekunden an, die darauf gewartet werden soll, dass andere Benutzer die Sperre aufheben, um unbegrenztes Warten zu verhindern.

Die Vorteile der „USE FOR UPDATE WAIT“-Klausel sind wie folgt:
1. Verhindert das unbegrenzte Warten auf gesperrte Zeilen; 2. Ermöglicht der Anwendung eine bessere Kontrolle über die Sperrwartezeit.
　3 Sehr nützlich für interaktive Anwendungen, da diese Benutzer nicht unbegrenzt warten können
　4 Wenn „Überspringen gesperrt“ verwendet wird, können die gesperrten Zeilen übersprungen werden und der durch Warten n verursachte Ausnahmebericht „Ressource ausgelastet“ wird nicht gemeldet

Beispiel 2

Angenommen, es gibt ein Formular „products“, das zwei Felder hat, „id“ und „name“, und „id“ ist der Primärschlüssel.

Beispiel 1: (Geben Sie den Primärschlüssel explizit an, und es gibt diese Daten, Zeilensperre)

SELECT * FROM products WHERE id='3' FOR UPDATE;
SELECT * FROM products WHERE id='3' and type=1 FOR UPDATE;

Beispiel 2: (Geben Sie den Primärschlüssel explizit an, wenn keine solchen Daten vorhanden sind , es gibt kein Schloss)

SELECT * FROM products WHERE id='-1' FOR UPDATE;

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

SELECT * FROM products WHERE name='Mouse' FOR UPDATE;

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

SELECT * FROM products WHERE id<>&#39;3&#39; FOR UPDATE;

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

SELECT * FROM products WHERE id LIKE '3' FOR UPDATE;

Hinweis 1: FOR UPDATE gilt nur für InnoDB und muss sich im Transaktionsblock (BEGIN/COMMIT) befinden, um wirksam zu werden.

Hinweis 2: Um die Sperrsituation zu testen, können Sie den Befehlsmodus von MySQL verwenden, um zwei Fenster zum Testen zu öffnen.

Dies ist tatsächlich der Fall, wenn es in MySql 5.0 getestet wurde.

Außerdem: MyAsim unterstützt nur Sperren auf Tabellenebene, während InnerDB Sperren auf Zeilenebene unterstützt.

Die Daten mit hinzugefügter Sperre (Sperre auf Zeilenebene/Sperre auf Tabellenebene) können weder von anderen Transaktionen gesperrt werden, noch können sie von anderen Transaktionen geändert (geändert, gelöscht) werden, wenn es sich um eine Tabellenebene handelt Sperre, unabhängig davon, ob der Datensatz abgefragt wird, Die Tabelle wird gesperrt.

Wenn A und B beide die Tabellen-ID abfragen, aber den Datensatz nicht abfragen können, führen A und B keine Zeilensperren für die Abfrage durch, aber sowohl A als auch B erhalten zu diesem Zeitpunkt exklusive Sperren. A Wenn Sie einen anderen Datensatz einfügen, wird dieser warten, da B bereits über die Sperre verfügt. Zu diesem Zeitpunkt fügt B die gleichen Daten erneut ein und löst beim Versuch, die Sperre zu erhalten, einen Deadlock aus. Zu diesem Zeitpunkt erhält A Die Sperre wurde erfolgreich eingefügt.

Wissensergänzung

Sperre ist ein sehr wichtiges Konzept in der Datenbank. Es wird hauptsächlich verwendet, um die Integrität und Konsistenz der Datenbank in einer Mehrbenutzerumgebung sicherzustellen. Wir wissen, dass es zu Dateninkonsistenzen kommt, wenn mehrere Benutzer gleichzeitig Daten in derselben Datenbank bearbeiten können. Das heißt, wenn keine Sperren vorhanden sind und mehrere Benutzer gleichzeitig auf eine Datenbank zugreifen, kann es zu Problemen kommen, wenn ihre Transaktionen gleichzeitig dieselben Daten verwenden. Zu diesen Problemen gehören: verlorene Updates, Dirty Reads, nicht wiederholbare Lesevorgänge und Phantom Reads:

1. Das Problem der verlorenen Aktualisierung tritt auf, wenn zwei oder mehr Transaktionen dieselbe Zeile auswählen und diese Zeile dann basierend auf dem ursprünglich ausgewählten Wert aktualisieren. Jede Transaktion ist sich der Existenz anderer Transaktionen nicht bewusst. Die letzte Aktualisierung überschreibt Aktualisierungen anderer Transaktionen, was zu Datenverlust führt. Beispielsweise erstellen zwei Redakteure elektronische Kopien desselben Dokuments. Jeder Redakteur nimmt selbstständig Änderungen an seiner Kopie vor und speichert dann die geänderte Kopie, wobei das Originaldokument überschrieben wird. Der letzte Bearbeiter, der eine Kopie seiner Änderungen speichert, überschreibt die vom ersten Bearbeiter vorgenommenen Änderungen. Dieses Problem kann vermieden werden, wenn der zweite Bearbeiter keine Änderungen vornehmen kann, bis der erste Bearbeiter fertig ist.

2. Dirty Reading bedeutet, dass, wenn eine Transaktion auf Daten zugreift und die Daten geändert hat, die Änderung jedoch noch nicht an die Datenbank übermittelt wurde, eine andere Transaktion ebenfalls auf die Daten zugreift und diese dann verwendet diese Daten. Da diese Daten noch nicht festgeschrieben wurden, handelt es sich bei den von einer anderen Transaktion gelesenen Daten um fehlerhafte Daten, und die auf den fehlerhaften Daten basierenden Vorgänge sind möglicherweise falsch. Beispielsweise nimmt ein Redakteur Änderungen an einem elektronischen Dokument vor. Während des Änderungsprozesses erstellt ein anderer Bearbeiter eine Kopie des Dokuments (die Kopie enthält alle bisher vorgenommenen Änderungen) und verteilt sie an die vorgesehenen Benutzer. Danach entschied der erste Redakteur, dass die bisher vorgenommenen Änderungen falsch waren, löschte die Änderungen und speicherte das Dokument. An Benutzer verteilte Dokumente enthalten Änderungen, die nicht mehr vorhanden sind und als nie vorhanden gelten. Dieses Problem kann vermieden werden, wenn niemand das geänderte Dokument lesen kann, bis der erste Bearbeiter die Änderungen finalisiert.

3． Unter nicht wiederholbarem Lesen versteht man das mehrmalige Lesen derselben Daten innerhalb einer Transaktion. Bevor diese Transaktion endet, greift auch eine andere Transaktion auf dieselben Daten zu. Dann können zwischen den beiden Lesevorgängen der Daten in der ersten Transaktion aufgrund der Änderung der zweiten Transaktion die von der ersten Transaktion zweimal gelesenen Daten unterschiedlich sein. Auf diese Weise sind die innerhalb einer Transaktion zweimal gelesenen Daten unterschiedlich und werden daher als nicht wiederholbares Lesen bezeichnet. Beispielsweise liest ein Redakteur dasselbe Dokument zweimal, aber zwischen den Lesevorgängen schreibt der Autor das Dokument neu. Wenn der Redakteur das Dokument ein zweites Mal liest, hat sich das Dokument geändert. Rohlesevorgänge sind nicht wiederholbar. Dieses Problem kann vermieden werden, wenn Redakteure das Dokument erst dann lesen können, wenn der Autor mit dem Schreiben fertig ist.

4. Phantom-Lesen bezieht sich auf ein Phänomen, das auftritt, wenn Transaktionen nicht unabhängig voneinander ausgeführt werden. Beispielsweise werden bei der ersten Transaktion die Daten in einer Tabelle geändert, und diese Änderung betrifft alle Datenzeilen in der Tabelle. Gleichzeitig werden durch die zweite Transaktion auch die Daten in dieser Tabelle geändert. Durch diese Änderung wird eine Zeile mit neuen Daten in die Tabelle eingefügt. Dann wird der Benutzer, der die erste Transaktion ausführt, in Zukunft feststellen, dass die Tabelle immer noch unveränderte Datenzeilen enthält, als ob eine Halluzination aufgetreten wäre. Beispielsweise ändert ein Redakteur ein von einem Autor eingereichtes Dokument, aber wenn die Produktion seine Änderungen in die Masterkopie des Dokuments einfügt, stellt sich heraus, dass der Autor dem Dokument neues, unbearbeitetes Material hinzugefügt hat. Dieses Problem kann vermieden werden, wenn niemand neues Material zum Dokument hinzufügen kann, bis die Redaktion und die Produktionsabteilung die Arbeit am Originaldokument abgeschlossen haben.

Daher besteht die Möglichkeit, den gleichzeitigen Zugriff mehrerer Benutzer zu handhaben, darin, ihn zu sperren. Sperren sind ein wichtiges Mittel, um zu verhindern, dass andere Transaktionen auf bestimmte Ressourcenkontrollen zugreifen und eine Parallelitätskontrolle erreichen. Wenn ein Benutzer ein Objekt in der Datenbank sperrt, können andere Benutzer nicht mehr auf das Objekt zugreifen. Die Auswirkung der Sperrung auf den gleichzeitigen Zugriff spiegelt sich in der Granularität der Sperre wider. Um gesperrte Ressourcen zu kontrollieren, sollten Sie zunächst die Speicherplatzverwaltung des Systems verstehen.

Das Obige ist der Inhalt von MySQL Select in Advanced MySQL (4). Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php.cn)!