我正在运行以下MySQL UPDATE语句:
mysql> update customer set account_import_id = 1;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
我没有使用事务,为什么会得到这个错误?我甚至尝试重新启动我的MySQL服务器,它没有帮助。
该表有406,733行。
我正在运行以下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会给你一些死锁原因的线索。还要仔细查看慢速查询日志,看看还有什么正在查询表,并尝试删除正在执行满表罐操作的任何内容。行级锁定工作得很好,但当您试图锁定所有行的时候就不行了!