MySQL DDL 被元数据锁阻塞的定位方案

我处理过一次“DDL 明明用了 LOCK=NONE，线上查询却越来越慢”的变更。真正的问题不是 ALTER TABLE 一直复制数据，而是一个没有及时提交的事务持有表的元数据锁，DDL 在提交新表定义时等待独占锁；一旦独占请求排在队列里，后续访问同一张表的会话也可能继续排队。定位这类故障，重点是先找等待者，再找持锁者，最后决定是否让事务结束或把变更移到窗口内。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/metadata-locking.html

为什么一条 DDL 会把后续查询一起拖住

元数据锁保护的是表定义等对象的并发访问，不是 InnoDB 行锁的替代名称。一个事务即使只是读取表，也可能在事务结束前保留共享元数据锁。DDL 需要修改定义时，会在某些阶段请求更强的锁；在线 DDL 减少了阻塞范围，并不意味着它永远不等待。

典型链条是：会话 A 开启事务后读取 orders，会话 B 执行 ALTER TABLE orders ... 并等待独占元数据锁，会话 C 随后读取同一张表。此时 B 的等待状态是线索，C 的排队是影响面，A 是否已经提交才是处理关键。

先用 processlist 确认等待者和影响面

故障刚出现时，我会先保留一份完整的进程现场。只看客户端报错容易把问题误判为“DDL 太慢”，而 processlist 能直接告诉我们等待状态、持续时间、数据库和正在执行的 SQL。

-- 保留完整 SQL，先区分 DDL 等待与后续查询排队
SHOW FULL PROCESSLIST;

-- 只筛选常见元数据锁等待，便于快速确认影响面
SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO
FROM information_schema.PROCESSLIST
WHERE STATE = 'Waiting for table metadata lock'
ORDER BY TIME DESC;

重点记录 ID、TIME、STATE 和 INFO。如果只有 ALTER TABLE 在等待，可能只是一个旧事务挡住了提交；如果 SELECT、UPDATE 也同时等待，说明独占锁请求已经改变了后续会话的排队关系。不要把 TIME 当作事务年龄，它只是当前命令持续时间。

用 metadata_locks 把持锁线程找出来

performance_schema.metadata_locks 提供对象、锁类型、锁状态和拥有者线程等信息；再把线程映射到 processlist 的连接 ID，才能把抽象的线程关系还原成可处理的会话。不同版本和权限配置下可见字段可能受限，因此查询不到记录时先确认 Performance Schema 与相应 instrument 是否可用。

-- 把元数据锁映射到客户端连接，区分持有和等待请求
SELECT
    ml.OBJECT_SCHEMA,
    ml.OBJECT_NAME,
    ml.LOCK_TYPE,
    ml.LOCK_STATUS,
    t.THREAD_ID,
    t.PROCESSLIST_ID,
    t.PROCESSLIST_USER,
    t.PROCESSLIST_HOST,
    t.PROCESSLIST_INFO
FROM performance_schema.metadata_locks AS ml
JOIN performance_schema.threads AS t
  ON t.THREAD_ID = ml.OWNER_THREAD_ID
WHERE ml.OBJECT_TYPE = 'TABLE'
ORDER BY ml.OBJECT_SCHEMA, ml.OBJECT_NAME, ml.LOCK_STATUS;

同一张表上，GRANTED 表示已经持有的请求，PENDING 表示正在等待的请求。把 OBJECT_SCHEMA 和 OBJECT_NAME 与 DDL 目标对上，再用 PROCESSLIST_ID 回到 SHOW FULL PROCESSLIST，通常就能找到“谁在等”和“谁可能挡住它”。查询结果是快速变化的现场，不要把一次快照当成永久事实。

处理阻塞时先确认事务和变更窗口

定位到连接后，先问三个问题：它是否属于长事务，是否仍有未完成的业务操作，是否可以在当前变更窗口结束。能正常提交的事务优先让业务代码提交；确认连接已失控且有明确授权时，再考虑终止会话。直接结束持锁连接可能触发回滚、重试风暴或业务错误，不能把“解除等待”当成唯一目标。

-- 缩短本次 DDL 的等待上限，避免无限占住变更窗口
SET SESSION lock_wait_timeout = 60;

-- 先用完整语句复现目标变更，锁策略按本次 DDL 的兼容性选择
ALTER TABLE orders
  ADD COLUMN risk_level TINYINT NULL,
  ALGORITHM=INPLACE,
  LOCK=NONE;

lock_wait_timeout 控制获取元数据锁的等待时间，不能替代阻塞源治理；一条语句如果需要多个锁，实际等待可能累加。生产变更应提前确认 DDL 的算法、锁级别、回滚路径和业务低峰窗口，并在失败后保留 processlist 与 metadata_locks 的记录。

防止下一次 DDL 再被无意阻塞

我最后会把排查动作固化成发布前清单：先检查目标表是否有长事务访问，再确认连接池是否会借出带未提交事务的连接；执行 DDL 时设置本次会话的等待上限，记录失败现场；发布后观察同表的新请求是否恢复。这样做的重点不是保证任何 DDL 都“零等待”，而是让等待可见、可解释、可回退。

常见问题

使用 LOCK=NONE 就不会被元数据锁阻塞吗？

不会。LOCK=NONE 主要表示允许并发查询和 DML 的目标约束，DDL 在提交表定义等阶段仍可能请求独占元数据锁。

看到 Waiting for table metadata lock 就能直接杀掉最早的连接吗？

不能。最早的连接不一定是阻塞源；应按对象、锁状态、线程和事务现场确认，再结合业务授权选择提交、回滚、终止或延期。