MySQL Concurrency Plus für Updates ist nicht gesperrt

Ich habe eine lange Transaktion
Es gibt eine Sperre auf Zeilenebene im mittleren und hinteren Teil davon
Nach dem Testen wurde festgestellt, dass sie nicht gesperrt ist
aber wenn man diesen Teil herausnimmt separat kann es gesperrt werden
Unter welchen Umständen wirkt es sich während meiner gesamten langen Transaktion auf meine Sperre aus?
Wählen Sie die ID aus „product_term“ aus, wobei „Id=".$v['P_Term_id']" für die Aktualisierung gilt.

Antwortinhalt:

Ich habe eine lange Transaktion
Es gibt eine Sperre auf Zeilenebene im mittleren und hinteren Teil davon
Nach dem Testen wurde festgestellt, dass sie nicht gesperrt ist
aber wenn man diesen Teil herausnimmt Separat kann es
in meiner gesamten langen Transaktion gesperrt werden. Unter welchen Umständen wirkt es sich auf meine Sperre aus?
Wählen Sie die ID aus „product_term“ aus, wobei „Id=".$v['P_Term_id']" für die Aktualisierung gilt.

Die Einstellungen sind betroffen.
Eigentlich. . Lassen Sie mich zunächst eine Anfängerfrage stellen. . . Ist es Innodb? Ich bin schon einmal auf eine Frage zu Myisams Angelegenheiten gestoßen. .
Okay. Zurück zum Thema.
Exklusive Sperren sperren diesen Abfragebereich normalerweise bis zum Ende der Transaktion.
Genau wie du. Der der ID-Zeile entsprechende Datensatz wird gesperrt.
Aber entsprechend dem Isolationsmodus der Transaktion. Wenn Sie die Einstellungen nicht geändert haben, ist die Standardeinstellung RR. Das heißt, das SELECT, das Sie vor dieser exklusiven Sperre ausgeführt haben, hat das gleiche Ergebnis. . Dadurch entsteht die Illusion, dass es nicht gesperrt ist. .

Wenn Ihr Unternehmen so ist

<code>BEGIN;
SELECT id FROM product_term where id<100;
UPDATE product_term SET XXX='YYY' WHERE id = 1;
...
SELECT id FROM product_term where id=1 FOR UPDATE;
...
COMMIT;</code>

Auf diese Weise enthält die erste Bereichssuche aufgrund des standardmäßigen RR-Levels bereits id=1, und dann ist die unter derselben Transaktion erhaltene dritte Zeile dieselbe wie die erste Zeile. Tatsächlich wurden die Daten in dieser Zeile in der zweiten Zeile geändert. Wenn es zwei Parallelitäten gibt, kann es so aussehen, als ob die Tabelle nicht gesperrt ist~~
Es wird ausschließlich empfohlen, dies zu Beginn der Transaktion zu tun.
Ich weiß nicht, ob bei Ihnen dieses Problem auftritt? Wenn ja, können Sie den Transaktionsisolationsmodus sorgfältig studieren und feststellen, dass es weitere Fallstricke gibt