MySQL“锁表”超时？

Question

mysql LOCK TABLES语句的超时时间是多少？

到处都找不到。

我尝试将变量innodb_lock_wait_timeout设置为my.cnf，但它似乎与另一个(行级)锁相关，而不是与表锁相关。

简单地说，它对锁表没有影响。

我想在死锁的情况下设置一些低超时值，因为如果一些操作将锁定表，并发生错误，它将挂起整个网站！

这是愚蠢的，例如在你的网站上完成购买的情况下。

Answer 1

我的变通方法是创建一个专用的锁表，然后锁定该表中的一行。这样做的好处是只锁定那些特别想要锁定的进程。应用程序的其他部分可以继续访问表，即使它们在某个时刻被更新过程所触及。

设置

CREATE TABLE `mutex` (
    EMPTY ENUM('') NOT NULL,
    PRIMARY KEY (EMPTY)
);

用法

set innodb_lock_wait_timeout = 1;
start transaction;
insert into `mutex` values();

[... do the real work here ... or somewhere else ... even a different machine ...]

delete from `mutex`;
commit;

Answer 2

为什么要使用LOCK TABLES

如果您使用的是MyISAM (有时需要LOCK TABLES)，则应转换为InnoDB。

如果您使用的是InnoDB，则永远不要使用LOCK TABLES。取而代之的是依赖于innodb_lock_wait_timeout (默认值是不合理的高达50秒)。并且您应该检查错误。

InnoDB死锁被捕获并立即导致错误。某些非死锁可能会等待innodb_lock_wait_timeout。

编辑

由于事务看起来像这样

BEGIN;
SELECT ...;
compute some stuff
UPDATE ... (using that stuff);
COMMIT;

您需要在SELECT的末尾添加FOR UPDATE。

Answer 3

我认为你想要的是table_lock_timout变量，它是在MySQL 5.0.10中引入的，但后来是removed in 5.5。不幸的是，发布说明并没有指定使用的替代方案，我猜一般的态度是切换到使用InnoDB事务，就像@Rick James在他的回答中所说的那样。

我认为删除变量是没有帮助的。其他人可能认为这是XY Problem的情况，我们试图通过更改锁定表的超时期限来修复症状(死锁)，而实际上我们应该通过切换到事务来解决根本原因。我认为在某些情况下，表锁比使用事务更适合应用程序，并且可能更容易理解，即使它们的性能较差。

使用LOCK TABLES的好处是，您可以在继续之前声明查询所依赖的表。对于事务，锁在最后可能的时刻被抓住，如果它们不能被获取和超时，那么您需要检查此故障并回滚，然后再重新尝试所有事情。更简单的方法是在lock tables查询上设置1秒的超时(最短时间)，然后不断重试获取锁，直到成功，然后在解锁表之前继续查询。这个逻辑没有死锁的风险。

我相信开发者的态度可以从下面的documetation摘录中总结出来

...avoid使用LOCK TABLES语句，因为它没有提供任何额外的保护，而是减少了并发性。