深度解析：为什么简单的数据库"写操作"会在 MySQL 中卡住？

在进行数据库维护时，我们经常会用到数据库写操作，例如： RENAME TABLE 操作，通常这只是一个极快的元数据修改过程。然而，在某些特定的场景下，这个操作会突然"卡住"，导致整个数据库连接挂起。

本文将结合一次真实的排查经历，深入分析 MySQL 元数据锁（Metadata Lock） 导致的阻塞问题及其解决方案。

1. 现象描述

在对某业务库进行表名变更时，执行如下 SQL：

sql 复制代码

RENAME TABLE `prod_db`.`order_info_bak` TO `prod_db`.`order_info`;

执行后，客户端没有任何响应，查询一直处于挂起状态。通过其他连接观察，发现该操作引发了连锁反应，后续针对该表的所有查询也开始出现排队现象。

通过 SHOW PROCESSLIST 命令，我们观察到了关键的阻塞状态：

sql 复制代码

SHOW PROCESSLIST;

执行结果示例：

Id	User	Host	db	Command	Time	State	Info
1556258	dev	10.0.0.1:5678	prod_db	Query	120	Waiting for table metadata lock	RENAME TABLE prod_db.order_info_bak TO ...
1555083	app	10.0.0.2:4321	prod_db	Sleep	7200		NULL

分析：进程 1556258 正在等待元数据锁。而进程 1555083 虽然处于 Sleep 状态，但由于它可能持有了锁且未释放，导致了 DDL 操作（重命名）无法获取 排他性元数据锁（Exclusive MDL）。

MDL 锁通常由未提交的事务持有。我们通过 InnoDB 的事务监控表进行排查：

sql 复制代码

SELECT trx_id, trx_state, trx_started, trx_mysql_thread_id, trx_query 
FROM information_schema.innodb_trx 
ORDER BY trx_started;

执行结果示例：

trx_id	trx_state	trx_started	trx_mysql_thread_id	trx_query
537112116	RUNNING	2026-02-27 10:00:00	1555083	NULL

发现：线程 1555083 对应一个已运行超过 2 小时的活跃事务（RUNNING）。虽然当前没有执行任何 SQL（trx_query 为空），但该事务并未提交。

为什么简单的查询会一直持有事务不释放？我们检查了数据库的全局变量：

sql 复制代码

SHOW VARIABLES LIKE 'autocommit';

执行结果示例：

Variable_name	Value
autocommit	OFF

根本原因 ：在 autocommit = OFF 模式下，任何一个 SELECT 都会隐式开启一个事务。如果开发人员或管理工具（如 DBeaver, Navicat）在执行查询后没有手动点击 COMMIT，该连接就会一直持有元数据锁，直到连接超时断开。

MySQL 为了保证在并发环境下 DDL 操作与 DML 操作的一致性，引入了 Metadata Lock (MDL)。

阻塞逻辑：

如果一个长事务正在进行 SELECT（未提交），它持有了共享锁。
此时执行 RENAME TABLE，它会申请排他锁，但由于共享锁未释放，它必须进入队列等待。
更严重的是 ：一旦 DDL 开始在队列中等待排他锁，它会阻塞之后所有新进入的共享锁申请。这意味着，该表上的后续所有 SELECT 查询都会被卡住，从而引发系统雪崩。

要解决此问题，必须清理掉阻塞队列头部的"源头"。

终止阻塞源进程 ：根据 innodb_trx 中找到的线程 ID，强制终止这些长事务连接：
sql 复制代码
```
KILL 1555083; -- 终止那个运行了2小时的僵尸事务
```

清理挂起的 DDL 进程 ：

sql 复制代码

KILL 1556258; -- 终止之前卡住的重命名操作，重新开始

通过这次排查，我们深刻理解到：在 autocommit=OFF 的环境下，一个被遗忘的 SELECT 也能成为摧毁系统性能的导火索。