我正在运行以下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数据。

其他回答

我在使用php时遇到过这种情况 语言构念退出;正在进行交易。那么这个 事务“挂起”,你需要杀死mysql进程(如上所述processlist;)

行数并不大……如果account_import_id不是主键,则在它上创建一个索引。

CREATE INDEX idx_customer_account_import_id ON customer (account_import_id);
mysql->SHOW PROCESSLIST;
kill xxxx; 

然后杀了睡着的那个。对我来说是2156。

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

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

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

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

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

完全符合MarkR的说法。自动提交使每个语句成为一个语句事务。

SHOW ENGINE INNODB STATUS会给你一些死锁原因的线索。还要仔细查看慢速查询日志,看看还有什么正在查询表,并尝试删除正在执行满表罐操作的任何内容。行级锁定工作得很好,但当您试图锁定所有行的时候就不行了!