我正在运行以下MySQL UPDATE语句:

mysql> update customer set account_import_id = 1;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

我没有使用事务,为什么会得到这个错误?我甚至尝试重新启动我的MySQL服务器,它没有帮助。

该表有406,733行。


当前回答

我有2个Doctrine DBAL连接,其中一个是非事务性的(用于重要日志),它们旨在并行运行,而不是相互依赖。

CodeExecution(
    TransactionConnectionQuery()
    TransactionlessConnectionQuery()
)

我的集成测试被包装到事务中,以便在每次测试后进行数据回滚。

beginTransaction()
CodeExecution(
    TransactionConnectionQuery()
    TransactionlessConnectionQuery() // CONFLICT
)
rollBack()

我的解决方案是在这些测试中禁用包装事务,并以另一种方式重置db数据。

其他回答

某些东西阻塞了查询的执行。很可能是另一个查询更新、插入或删除查询中的某个表。你必须找出那是什么:

SHOW PROCESSLIST;

一旦你找到阻塞进程,找到它的id并运行:

KILL {id};

重新运行初始查询。

我在使用python访问mysql数据库时遇到了类似的错误。 python程序使用了while和for循环。 关闭游标和链接在适当的行解决问题 https://github.com/nishishailesh/sensa_host_com/blob/master/sensa_write.py 见第230行 似乎是询问重复链接而没有关闭前一个链接产生了这个错误

您是否可以更新这个表中的任何其他记录,或者这个表是否被大量使用?我想的是,当它试图获得一个锁,它需要更新这条记录时,设置的超时已经超时。你可以延长时间,这可能会有所帮助。

我们昨天遇到了这个问题,在仔细研究了这里的每一个建议的解决方案,以及其他答案/论坛的其他几个解决方案后,我们最终在意识到实际问题时解决了它。

由于一些糟糕的计划,我们的数据库存储在一个挂载的卷上,该卷也接收我们的常规自动备份。该容量已达到最大容量。

一旦我们清理了一些空间并重新启动,这个错误就被解决了。

注意,我们也手动终止了几个进程:kill <process_id>;所以这仍然是必要的。

总的来说,我们的结论是,令人难以置信的是,我们的日志或警告都没有直接提到磁盘空间不足,但这似乎确实是根本原因。

在我的实例中,我正在运行一个异常查询来修复数据。如果你在你的查询中锁定了表,那么你将不必处理锁定超时:

LOCK TABLES `customer` WRITE;
update customer set account_import_id = 1;
UNLOCK TABLES;

这对于正常使用可能不是一个好主意。

更多信息请参见:MySQL 8.0参考手册