mysql->SHOW PROCESSLIST;
kill xxxx; 

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

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

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

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

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

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

mysql> set innodb_lock_wait_timeout=100;

Query OK, 0 rows affected (0.02 sec)

mysql> show variables like 'innodb_lock_wait_timeout';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| innodb_lock_wait_timeout | 100   |
+--------------------------+-------+

现在再打开锁。你有100秒的时间向数据库发出一个SHOW ENGINE INNODB STATUS\G，并查看其他哪个事务正在锁定你的事务。

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

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

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

CREATE INDEX idx_customer_account_import_id ON customer (account_import_id);

您正在使用一个事务;Autocommit不会禁用事务，它只是让它们在语句的末尾自动提交。

可能发生的情况是，其他一些线程在某个记录上持有记录锁(您正在更新表中的每个记录!)太长时间，而您的线程正在超时。或者在一个事务中对同一行运行多个(2+)UPDATE查询。

可以通过发出命令查看事件的更多详细信息

SHOW ENGINE INNODB STATUS

事件发生后(在SQL编辑器中)。理想情况下，在安静的测试机上执行此操作。