mysql为什么会出现MetadataLock锁等待_长事务未提交导致的DDL阻塞-mysql教程-PHP中文网

MySQL出现Waiting for table metadata lock的主因是未提交事务长期持有MDL锁，阻塞DDL及后续所有表操作；常见场景包括长事务、显式BEGIN后遗忘COMMIT、autocommit=OFF连接池滞留等。

mysql为什么会出现metadatalock锁等待_长事务未提交导致的ddl阻塞

为什么 `SHOW PROCESSLIST` 里会看到 `Waiting for table metadata lock`

这不是行锁或事务锁，而是元数据锁（MDL），MySQL 在执行 DDL（如 ALTER TABLE、DROP TABLE）前必须获取 MDL_EXCLUSIVE 锁；而任何活跃的 DML/SELECT（哪怕只是 SELECT * FROM t LIMIT 1）在事务中未提交，都会持有 MDL_SHARED_READ 或 MDL_SHARED_WRITE 锁，阻塞后续 DDL 的排他请求。

关键点在于：只要事务没 COMMIT 或 ROLLBACK，哪怕只执行了一条 SELECT，MDL 锁就一直不释放。此时新发起的 ALTER 就卡在 Waiting for table metadata lock 状态，且这个等待会**传染**——后续所有对该表的查询、更新也会被一起堵住。

常见诱因是开发/DBA 在客户端（如 DBeaver、MySQL CLI）手动 BEGIN 后只查了数据却忘了 COMMIT，连接挂着不动
autocommit=OFF 的连接池配置（如未显式设 autocommit=True 的 aiomysql）也容易导致隐式事务长期滞留
长查询（如未加 LIMIT 的全表扫描）本身不开启事务，但会持有一个短暂的 MDL_SHARED_READ，在它执行期间 DDL 会被阻塞

`KILL` 哪个线程才能真正解阻塞

不能只看 State 是 Waiting for table metadata lock 的线程——那是“受害者”，真正要 KILL 的是“持有者”：即那个开启了事务、执行过操作、但至今没提交的连接。

用下面语句定位源头：

SELECT 
  ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO 
FROM information_schema.PROCESSLIST 
WHERE COMMAND != 'Sleep' AND TIME > 60 
ORDER BY TIME DESC;

重点关注 COMMAND 为 Query 或 Sleep 但 TIME 很大的线程，尤其是 INFO 字段显示有 SELECT、UPDATE、BEGIN 等且长时间没变化的。这类线程大概率就是 MDL 持有者。

不要 KILL 正在 alter table 的线程——它只是等锁，杀掉后重试还会卡住
如果 PROCESSLIST 里找不到明显长事务，检查是否还有未关闭的旧连接（比如应用异常退出但连接没回收）
某些场景下（如两个事务都在 COMMIT 阶段），PROCESSLIST 可能不体现锁等待，需结合 performance_schema.metadata_locks 查看（MySQL 5.7+）

`innodb_lock_wait_timeout` 和 MDL 锁等待是两回事

innodb_lock_wait_timeout 控制的是 InnoDB 行锁等待超时（比如两个事务争同一行），单位秒，默认 50；而 MDL 锁等待没有对应可调参数，它由持有者生命周期决定——你无法通过改配置让 DDL “自动放弃等待”，只能等持有者释放或被干掉。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

所以当看到 ERROR 1205 (HY000): Lock wait timeout exceeded，先确认是不是行锁问题；如果是 Waiting for table metadata lock 卡住，则改 innodb_lock_wait_timeout 完全无效。

误配 innodb_lock_wait_timeout = 1 可能让业务频繁报错回滚，但对 DDL 阻塞毫无帮助
DDL 卡住时，SHOW ENGINE INNODB STATUS 的 TRANSACTIONS 部分通常看不到线索，因为 MDL 不属于 InnoDB 层
真正影响 DDL 执行时间的是表大小、I/O 负载、online DDL 支持度，不是锁等待参数

如何避免下次再被 MDL 锁卡住

核心原则：不让事务意外“活”太久。生产环境尤其要约束客户端行为和连接池配置。

在应用层：

所有数据库连接池初始化时强制设置 autocommit=True（如 aiomysql.create_pool(..., autocommit=True)），避免隐式事务
禁止在业务代码里手动写 BEGIN/START TRANSACTION，除非明确需要跨多语句一致性
对管理类工具（DBeaver、Navicat）启用“执行后自动提交”或“断开连接时自动回滚未提交事务”选项

在运维侧：

定期巡检：SELECT * FROM information_schema.PROCESSLIST WHERE TIME > 300 AND COMMAND != 'Sleep';
配置 wait_timeout 和 interactive_timeout（如设为 300 秒），让空闲连接自动断开
DDL 操作尽量选在低峰期，并提前用 pt-online-schema-change 或 MySQL 8.0+ 的 ALGORITHM=INSTANT 降低锁表风险

最常被忽略的一点：MDL 锁的持有者未必是“正在运行”的语句，而可能是早已执行完、只差一个 COMMIT 的静默事务——盯住 TIME 列比盯住 STATE 更有效。