所以选择更新的语法类似于
SELECT * //1st query
FROM test
WHERE id = 4 FOR UPDATE;
UPDATE test //2nd query
SET parent = 100
WHERE id = 4;
我猜锁定部分是第一行。
因此,当第一组查询执行时,我应该无法选择和修改带有
id = 4
的行。 (顺便说一下,它是主键)。但是,我仍然可以使用 id = 4
选择行在我更新任何东西之前,这意味着另一个线程可能会进入并尝试在第二行命中之前选择和更新同一行,从而导致并发问题。但是当我像下面这样锁定整个表格时
LOCK TABLES test WRITE;
其他事务正在挂起并等待锁定被释放。我想使用的唯一原因
SELECT FOR UPDATE
而不是表锁是因为这里引用的原因https://dev.mysql.com/doc/refman/5.7/en/lock-tables-and-transactions.html如果我只是在这里引用它们,则如下所示
LOCK TABLES does not play well with transactions. Even if you use the "SET autommit=0" syntax you can find undesired side effects. For instance, issuing a second LOCK TABLES query within a transaction will COMMIT your pending changes:
SET autocommit=0;
LOCK TABLES foo WRITE;
INSERT INTO foo (foo_name) VALUES ('John');
LOCK TABLES bar WRITE; -- Implicit commit
ROLLBACK; -- No effect: data already committed
In many cases, LOCK TABLES can be replaced by SELECT ... FOR UPDATE which is fully transaction aware and doesn't need any special syntax:
START TRANSACTION;
SELECT COUNT(*) FROM foo FOR UPDATE; -- Lock issued
INSERT INTO foo (foo_name) VALUES ('John');
SELECT COUNT(*) FROM bar FOR UPDATE; -- Lock issued, no side effects
ROLLBACK; -- Rollback works as expected
因此,如果我可以在实际更新发生之前访问为更新选择的行,那么
SELECT FOR UPDATE
究竟是什么?锁定?另外,如何测试行是否在我的应用程序中被锁定? (它显然不适用于我编写的第一组查询)该表是使用 InnoDB 引擎创建的
弗朗西斯科的解决方案
下面的两个解决方案都导致 parent 为 1
UPDATE test
SET parent = 99
WHERE id = 4;
COMMIT;
START TRANSACTION;
SELECT *
FROM test
WHERE id = 4 FOR UPDATE;
UPDATE test
SET parent = 98
WHERE id = 4; //don't commit
START TRANSACTION;
SELECT *
FROM test
WHERE parent = 98 FOR UPDATE; //commit did not happens so the id=4 document would still be parent = 99
UPDATE test
SET parent = 1
WHERE id = 4;
COMMIT; //parent = 1 where id = 4
另一个只是将父条件更改为 99 而不是 98
UPDATE test
SET parent = 99
WHERE id = 4;
COMMIT;
START TRANSACTION;
SELECT *
FROM test
WHERE id = 4 FOR UPDATE;
UPDATE test
SET parent = 98
WHERE id = 4; //Don't commit
START TRANSACTION;
SELECT *
FROM test
WHERE parent = 99 FOR UPDATE; //targets parent = 99 this time but id=4 still results in parent =1
UPDATE test
SET parent = 1
WHERE id = 4;
COMMIT;
第一组查询就像 id=4 文档首先提交给 parent = 98 一样运行。但是,第二组查询运行时好像 id=4 文档尚未提交给 parent = 99。如何在此处保持一致性?
最佳答案
一个 SELECT FOR UPDATE
锁定您选择更新的行,直到您创建的事务结束。其他事务只能读取该行,但只要选择更新事务仍处于打开状态,它们就无法更新它。
为了锁定行:
START TRANSACTION;
SELECT * FROM test WHERE id = 4 FOR UPDATE;
# Run whatever logic you want to do
COMMIT;
上面的事务将处于事件状态并将锁定该行直到它被提交。
为了测试它,有不同的方法。我使用两个终端实例对它进行了测试,每个实例都打开了 MySQL 客户端。
关于
first terminal
你运行 SQL:START TRANSACTION;
SELECT * FROM test WHERE id = 4 FOR UPDATE;
# Do not COMMIT to keep the transaction alive
关于
second terminal
您可以尝试更新该行:UPDATE test SET parent = 100 WHERE id = 4;
由于您在
first terminal
上创建了更新选择上面的查询将等待直到 select for update 事务提交或超时。返回
first terminal
并提交交易:COMMIT;
检查
second terminal
并且您将看到更新查询已执行(如果它没有超时)。
关于Mysql 选择更新 - 它没有锁定目标行。我如何确保它确实如此?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/48963451/