确保数据库表使用InnoDB存储引擎和READ-COMMITTED事务隔离级别。

你可以通过SELECT @@GLOBAL来检查它。tx_isolation @@tx_isolation;在mysql控制台。

如果没有设置为READ-COMMITTED，则必须设置它。在设置之前，请确保您在mysql中拥有SUPER权限。

你可以从http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html上获得帮助。

通过设置这个，我认为你的问题会得到解决。

您可能还希望检查是否试图同时在两个进程中更新此文件。用户(@tala)在这种情况下遇到了类似的错误消息，可能需要仔细检查…

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

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

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，并查看其他哪个事务正在锁定你的事务。

在我们的案例中，这个问题与锁本身没有太大关系。

问题是我们的一个应用程序端点需要并行打开2个连接来处理单个请求。

例子:

打开第一个连接 开始事务1 锁定表1中的一行 打开第二个连接 启动事务2 锁定表2中的一行 提交事务2 释放第二个连接 提交事务1 释放第一个连接

我们的应用程序的连接池限制为10个连接。

不幸的是，在负载下，一旦所有连接都被使用，应用程序就停止工作，我们开始遇到这个问题。 我们有几个请求需要打开第二个连接才能完成，但由于连接池的限制而无法完成。因此，这些请求长时间保持对table1行的锁定，导致接下来需要锁定同一行的请求抛出此错误。

解决方案:

在短期内，我们通过增加连接池限制修补了这个问题。 从长远来看，我们删除了所有嵌套连接，以完全解决问题。

小贴士:

您可以通过尝试将连接池限制降低到1并测试应用程序来轻松检查是否有嵌套连接。

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

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

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

SHOW ENGINE INNODB STATUS

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

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

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

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

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