使用 autocommit = 0 和 InnoDB 表的 LOCK TABLES 检测死锁

Question

https://dev.mysql.com/doc/refman/8.0/en/innodb-deadlock-detection.html

如果 innodb_table_locks = 1（默认值）和 autocommit = 0，则 InnoDB 知道表锁，并且它上面的 MySQL 层知道行级锁。 否则，InnoDB 无法检测到涉及 MySQL LOCK TABLES 语句设置的表锁或 InnoDB 以外的存储引擎设置的锁的死锁。 通过设置 innodb_lock_wait_timeout 系统变量的值来解决这些情况。

根据文档，我知道使用 innodb 表和使用 LOCK TABLES 如下所示将检测死锁：

SET autocommit=0;
LOCK TABLES t1 WRITE, t2 READ, ...;
... do something with tables t1 and t2 here ...
COMMIT;
UNLOCK TABLES;

这是正确的还是我误解了？ 请纠正我

Answer 1

如果您使用单个 LOCK TABLES 语句来锁定您将在事务期间访问的所有表，那么这些表将被自动锁定。 没有死锁的机会。

例如，在您包含在问题中的示例（手册中显示的示例）中，由于您锁定了表t1和t2 ，因此尝试锁定其中任何一个表的并发 session 将被阻止。 或者如果并发的 session 首先锁定它们，那么你的 session 将被两个表锁阻塞。 等待的人不会锁定任何一个表，直到另一个表解锁。

如果会话一次锁定一个表，这不是原子的，如果它们累积锁，那么它们可能会锁定一个表，然后在等待另一个表上的锁时被阻塞。 因此，这将是一个僵局。

事实上，它们不会通过连续的 LOCK TABLES 语句累积表锁。

https://dev.mysql.com/doc/refman/8.0/en/lock-tables.html ：

UNLOCK TABLES 显式释放当前 session 持有的任何表锁。LOCK TABLES 在获取新锁之前隐式释放当前 session 持有的任何表锁。

所以不会发生死锁。 如果您尝试一个接一个地执行 LOCK TABLES，您实际上让另一个 session 获得了您的 session 持有的表锁。 所以没有僵局。