如何强制解锁 MySQL 中锁定的表：                    

像这样破坏锁可能会导致数据库中的原子性无法对导致锁的 sql 语句强制执行。                    

这是 hackish，正确的解决方案是修复导致锁定的应用程序。然而，当美元岌岌可危时，迅速的一脚会让事情再次发生变化。                    

1）进入MySQL                    

mysql -u your_user -p

2）让我们看看锁定表的列表                    

mysql> show open tables where in_use>0;

3）让我们看看当前进程的列表，其中之一正在锁定您的表                    

mysql> show processlist;

4）杀死其中一个进程                    

mysql> kill <put_process_id_here>;

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   |
+--------------------------+-------+

现在再次触发锁定。SHOW ENGINE INNODB STATUS\G您有 100 秒的时间向数据库发出 a并查看哪个其他事务正在锁定您的事务。                    

看一下您的数据库是否经过微调，尤其是事务隔离。增加变量不是一个好主意innodb_lock_wait_timeout。                    

检查 MySQL 中的数据库事务隔离级别：                    

mysql> SELECT @@GLOBAL.tx_isolation, @@tx_isolation, @@session.tx_isolation;
+-----------------------+-----------------+------------------------+
| @@GLOBAL.tx_isolation | @@tx_isolation  | @@session.tx_isolation |
+-----------------------+-----------------+------------------------+
| REPEATABLE-READ       | REPEATABLE-READ | REPEATABLE-READ        |
+-----------------------+-----------------+------------------------+
1 row in set (0.00 sec)

您可以获得更改隔离级别的改进。使用类 OracleREAD COMMITTED而不是REPEATABLE READ. REPEATABLE READ是 InnoDB 的默认值。                    

mysql> SET tx_isolation = 'READ-COMMITTED';
Query OK, 0 rows affected (0.00 sec)

mysql> SET GLOBAL tx_isolation = 'READ-COMMITTED';
Query OK, 0 rows affected (0.00 sec)

另外，尽量只在必要时使用SELECT FOR UPDATE。                    

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

SHOW PROCESSLIST;

找到阻塞进程后，找到它id并运行：                    

KILL {id};

重新运行您的初始查询。                    

mysql->SHOW PROCESSLIST;
kill xxxx; 

然后在睡眠中杀死哪个。在我的例子中是 2156。                    

100% 与 MarkR 所说的一致。autocommit 使每个语句成为一个语句事务。                    

SHOW ENGINE INNODB STATUS应该给你一些关于死锁原因的线索。仔细查看您的慢速查询日志，看看还有什么在查询表，并尝试删除任何正在执行完整表扫描的内容。行级锁定效果很好，但当您尝试锁定所有行时效果不佳！                    

尝试更新以下两个参数，因为它们必须具有默认值。                    

innodb_lock_wait_timeout = 50                        

innodb_rollback_on_timeout = ON                        

要检查参数值，您可以使用以下 SQL。                    

显示像“innodb_rollback_on_timeout”这样的全局变量；                        

您能否更新此表中的任何其他记录，或者此表是否被大量使用？我在想的是，当它试图获取需要更新此记录的锁时，设置的超时已超时。您可以增加时间，这可能会有所帮助。                    

如果您刚刚终止了一个大查询，那么rollback. 如果您在终止的查询完成回滚之前发出另一个查询，您可能会收到锁定超时错误。那就是发生在我身上的事。解决办法只是稍等一下。                    

细节：                    

我发出了一个 DELETE 查询，从大约 100 万行中删除了大约 900,000 行。                    

我错误地运行了这个（只删除了 10% 的行）： DELETE FROM table WHERE MOD(id,10) = 0                    

而不是这个（删除 90% 的行）： DELETE FROM table WHERE MOD(id,10) != 0                    

我想删除 90% 的行，而不是 10%。所以我在 MySQL 命令行中终止了该进程，因为我知道它会回滚到目前为止已删除的所有行。                    

然后我立即运行了正确的命令，但lock timeout exceeded很快就报错了。我意识到锁实际上可能是rollback仍在后台发生的已终止查询的锁。所以我等了几秒钟，然后重新运行查询。                    

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

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

例子：                    

1. 打开第一个连接

2. 开始事务 1

3. 锁定 table1 中的 1 行

4. 打开第二个连接

5. 开始事务 2

6. 锁定 table2 中的 1 行

7. 提交事务 2

8. 释放第二个连接

9. 提交事务 1

10. 释放第一个连接

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

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

解决方案：                    

• 在短期内，我们通过增加连接池限制来修补该问题。

• 从长远来看，我们删除了所有嵌套连接，以彻底解决问题。

尖端：                    

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

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

CREATE INDEX idx_customer_account_import_id ON customer (account_import_id);

确保数据库表使用 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) 在这种情况下遇到过类似的错误消息，也许仔细检查一下......                    

我来自谷歌，我只是想添加适合我的解决方案。我的问题是我试图删除一个巨大的表的记录，该表有很多 FK 级联，所以我得到了与 OP 相同的错误。                    

我禁用了autocommit然后它只是COMMIT在 SQL 语句的末尾添加。据我了解，这会一点一点地释放缓冲区，而不是在命令结束时等待。                    

为了与 OP 的示例保持一致，这应该有效：                    

mysql> set autocommit=0;                    

mysql> update customer set account_import_id = 1; commit;                    

autocommit如果您想像以前一样保留 MySQL 配置，请不要忘记重新激活。                    

mysql> set autocommit=1;                    

晚会（像往常一样）但是我的问题是我写了一些糟糕的 SQL（作为新手）并且几个进程锁定了记录 < - 不确定适当的措辞。我最终不得不：SHOW PROCESSLIST然后使用杀死IDKILL <id>                    

我在使用php语言construct exit的时候就发生过这种事情；在交易中间。然后这个事务“挂起”，你需要杀死 mysql 进程（上面用 processlist 描述；）                    

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

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

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

有关详细信息，请参阅： MySQL 8.0 参考手册                    

我遇到了这个有 2 个 Doctrine DBAL 连接，其中一个是非事务性的（对于重要日志），它们旨在并行运行而不相互依赖。                    

CodeExecution(
    TransactionConnectionQuery()
    TransactionlessConnectionQuery()
)

在非常测试之后，我的集成测试被包装到事务中以进行数据回滚。                    

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

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

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

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

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

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

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

我在使用python访问mysql数据库时也有类似的错误。
python 程序使用了 while 和 for 循环。
在适当的行关闭光标和链接解决了问题
https://github.com/nishishailesh/sensa_host_com/blob/master/sensa_write.py 参见第 230 行
似乎在不关闭先前链接的情况下询问重复链接会产生此错误                    

我在做一些测试时遇到了类似的问题。                    

原因——在我的例子中，事务不是从我的 spring boot 应用程序提交的，因为我在执行期间杀死了 @transactional 函数（当函数正在更新某些行时）。由于哪个事务从未提交给数据库（MySQL）。                    

结果- 无法从任何地方更新这些行。但能够更新表的其他行。                    

mysql> update some_table set some_value = "Hello World" where id = 1;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

解决方案- 杀死所有使用的 MySQL 进程                    

• sudo killall -9 mysqld

• sudo killall -9 mysqld_safe（发生错误时重新启动服务器并将运行时信息记录到错误日志中。在我的情况下不需要）

我的场景在更新或删除后无法提交。                    

显示进程列表                    

显示了一长串睡眠连接。