MySQL 元数据锁 MDL 是什么？为什么 ALTER TABLE 会让后续查询一起阻塞？

知识点详解：一条等待中的 DDL，怎样把影响扩大？

MDL 保护的是对象结构，不是某一行

查询读取一张表，需要确定它的字段和结构。与此同时，另一个连接不能任意修改结构，让正在使用这张表的语句失去依据。

MDL 就承担这一类协调。它与 InnoDB 行锁保护的对象不同，不能因为查询使用一致性读，就判断不会受到任何锁等待影响。MDL 官方说明

查询结束，事务可能还没有结束

假设连接 A 开启事务，查询 orders，随后应用迟迟没有提交或回滚。

SELECT 已经返回了结果，但事务仍然打开，相关 MDL 可以继续保留。A 看起来处于空闲等待，也不能因此排除它是阻塞者。

连接 B 此时执行 ALTER TABLE，需要取得不兼容的锁，于是等待 A 结束。

自动提交语句与显式长事务的生命周期不同，排查时不能只看当前语句用了几秒。

后来的查询为什么也可能排队？

再让连接 C 查询同一张表。

虽然 C 的查询与 A 的读取可能兼容，但它不能保证直接绕过等待中的结构修改请求。MDL 有请求优先级和调度规则，等待的写请求可能影响后续读请求。

于是出现这条教学等待链：

连接	当前状态	影响
A	查询后事务未结束，持有 MDL	B 无法取得所需锁
B	ALTER TABLE 等待	可能影响 C 等后续读请求调度
C	新查询等待 MDL	接口请求开始堆积

这里用“可能”，不是承诺所有锁类型与所有设置下都严格按这一条顺序。真实原因应由锁信息证明。

排查要找链路，不是先终止一个连接

可以查看 Performance Schema 的 metadata_locks，区分 GRANTED 与 PENDING，再结合线程、事务与语句信息确认对象和持有者。观测表说明

接着判断：是不是遗留事务，DDL 是否可延期，后续请求是否正在积累，终止哪一步的风险最小。

有时先停止等待的 DDL 可以缓解后续压力，但这不应变成所有事故的固定答案。终止事务可能引起回滚，终止 DDL 也有执行阶段和资源影响，必须按实际情况处理并获得操作授权。

MDL 等待通常涉及 lock_wait_timeout；innodb_lock_wait_timeout 主要针对 InnoDB 行锁等待。改错参数，可能根本没有解决当前问题。

面试官继续追问

Online DDL 为什么也会等？

Online 描述的是特定操作阶段对并发的支持，不代表整个生命周期不需要元数据锁。开始、结束等阶段仍应按操作和算法核对。

把长事务的 SELECT 优化快一点就够了吗？

不一定。查询完成后如果事务仍不结束，锁依然可能保留。需要检查事务边界、异常路径和连接使用方式。

怎样避免上线改表时大面积阻塞？

先检查长事务与锁等待，确认 DDL 的算法、阶段和预算，在合适窗口执行并观察等待链。不能只在低峰期运行就假定没有风险。

面试速记卡

• MDL：协调对象结构的使用与修改，不是行锁。
• 长事务：语句结束不等于事务结束，MDL 可能继续持有。
• 等待链：持有者挡住 DDL，等待 DDL 又可能影响后续查询。
• 观测：metadata_locks 配合线程、事务和语句定位。
• 边界：Online DDL 仍可能需要 MDL，超时参数不要与行锁混淆。