MySQL 元数据锁等待怎么定位：从 performance_schema 找到阻塞会话

线上执行 ALTER TABLE orders 时，命令本身没有报错，却长时间停在 Waiting for table metadata lock；紧接着，原本正常的普通查询也开始排队。这个现场最容易误判成“DDL 运行太慢”，但真正挡住它的，往往是另一个已经打开事务、还没提交结束的会话。

先把“DDL 慢”拆成等待还是执行

ALTER TABLE 使用 ALGORITHM=INPLACE 或 LOCK=NONE，也不代表整个过程完全不需要元数据锁。在线 DDL 仍可能在开始或结束阶段申请短暂的排他元数据锁；如果这时有长事务持有表的元数据锁，DDL 就会先卡在排队状态。

第一步先看当前会话状态，不要马上重启 MySQL：

SHOW FULL PROCESSLIST;

如果 DDL 会话的状态是 Waiting for table metadata lock，先记录它的连接 ID、表名、执行 SQL 和等待时长。这个输出能说明“它在等锁”，但不一定直接告诉你“谁挡住了它”，所以还需要查 Performance Schema 里的相关表。

用 metadata_locks 找到同一对象的两类锁

确认元数据锁采集已经启用后，先过滤缩小到业务表和未完成的请求。下面的查询只保留了排障真正需要的列：

SELECT
    ml.OBJECT_SCHEMA,
    ml.OBJECT_NAME,
    ml.OBJECT_TYPE,
    ml.LOCK_TYPE,
    ml.LOCK_DURATION,
    ml.LOCK_STATUS,
    ml.THREAD_ID
FROM performance_schema.metadata_locks AS ml
WHERE ml.OBJECT_SCHEMA = 'shop'
  AND ml.OBJECT_NAME = 'orders'
ORDER BY ml.LOCK_STATUS, ml.THREAD_ID;

同一个 OBJECT_SCHEMA、OBJECT_NAME 对象下，GRANTED 行表示已经拿到锁，PENDING 行表示正在等待。不能只看 LOCK_TYPE 就断言冲突关系，最好再结合线程信息和当前 SQL 判断谁是发起 DDL 的会话、谁是持有锁的长期事务。

把 THREAD_ID 还原成连接、用户和 SQL

metadata_locks.THREAD_ID 不是 SHOW PROCESSLIST 里直接展示的连接 ID。把它和 performance_schema.threads 连接起来，才能看到会话身份和当前操作：

SELECT
    ml.OBJECT_SCHEMA,
    ml.OBJECT_NAME,
    ml.LOCK_TYPE,
    ml.LOCK_STATUS,
    ml.THREAD_ID,
    th.PROCESSLIST_ID,
    th.PROCESSLIST_USER,
    th.PROCESSLIST_HOST,
    th.PROCESSLIST_TIME,
    th.PROCESSLIST_STATE,
    th.PROCESSLIST_INFO
FROM performance_schema.metadata_locks AS ml
JOIN performance_schema.threads AS th
  ON th.THREAD_ID = ml.THREAD_ID
WHERE ml.OBJECT_SCHEMA = 'shop'
  AND ml.OBJECT_NAME = 'orders'
ORDER BY ml.LOCK_STATUS, th.PROCESSLIST_TIME DESC;

排查时通常这样读结果：先找到 DDL 对应的 PENDING 行，再找同一对象的 GRANTED 行；将持有线程的 PROCESSLIST_ID 带回进程列表，确认它是不是业务连接、空闲事务或后台任务。

如果 PROCESSLIST_INFO 为空，不要立即认为这个会话没有影响。事务可能已经执行完最后一条 SQL，但连接仍未提交；这时要结合应用事务日志、连接归属和会话状态继续确认。

权限、采集和结果时效要先说清楚

Performance Schema 的结果是运行时观测，不是持久化审计表。权限不足时，你可能只能看到自己的线程；观测表里的事件也可能随着锁释放而立即消失。因此建议把关键结果连同查询时间、实例、数据库名和连接 ID 一起保存到受控的排障记录中，但不要把密码、Cookie 或完整请求参数写进去。

如果查询不到预期信息，按这个顺序检查：

• 确认当前实例启用了 Performance Schema，并且 metadata_locks 表可访问。
• 确认账号有查看相关线程和 Performance Schema 表的权限。
• 用完全相同的库名、表名和对象类型过滤，避免把别的表或临时对象混进来。
• 把查询和 SHOW FULL PROCESSLIST 连续执行，防止锁已经释放后再去找不存在的记录。

终止阻塞会话前，先过三道安全检查

找到持有锁的连接 ID 后，最危险的动作不是查询，而是直接执行 KILL。持锁会话可能正处于付款、库存或批量写入事务中；终止它会触发回滚，回滚本身也可能继续占用大量资源。

建议先完成三项确认：

1. 确认连接 ID 与当前实例一致，且不是复制、监控、备份或管理员维护线程。
2. 联系业务侧确认事务归属，优先让应用正常提交或回滚；对明确失联的空闲事务，再评估终止操作。
3. 记录终止前的锁对象、用户、主机、SQL、事务时长和审批信息，便于后续回溯。

-- 仅在确认连接 12345 属于可终止的异常会话后执行
KILL CONNECTION 12345;

执行后重新查询元数据锁和进程列表，确认 PENDING 行消失、DDL 进入执行或结束状态；不要只看 KILL 返回成功就宣布故障恢复。

把发布窗口的元数据锁检查固定下来

需要频繁变更表结构的团队，可以在发布前做一次轻量检查：确认目标表没有长事务、没有正在等待的元数据锁，并为 DDL 设置明确的等待和回滚预案。应用侧还应避免打开事务后长时间停留在用户交互或远程调用环节。

常见问题

元数据锁和 InnoDB 行锁是一回事吗？

不是。元数据锁保护表、视图等对象的定义访问；行锁保护数据行。metadata_locks 主要用于定位前者，不能替代 InnoDB 的数据锁等待分析。

为什么 ALTER TABLE 使用 LOCK=NONE 仍然会等待？

在线 DDL 仍可能在特定阶段申请元数据锁。LOCK=NONE 降低的是对并发 DML 的阻塞范围，不等于完全不需要元数据锁。

查不到阻塞者时还能直接 KILL 吗？

不建议。锁可能已经释放，或者当前账号看不到其他线程。先确认采集、权限和实例，再重复查询；没有可靠连接 ID 和业务归属，就不应盲目终止。

杀掉持有者后 DDL 一定马上完成吗？

不一定。持有者可能需要回滚，DDL 也可能进入真正的执行阶段。应继续观察锁状态、进程状态和应用错误率，确认整条链路恢复。

MySQL 元数据锁排查可以收敛成一条可复查路径：先从 SHOW FULL PROCESSLIST 发现等待，再用 metadata_locks 找对象和状态，关联 threads 还原会话，最后按事务归属决定提交、回滚或终止。把“谁在等、谁持有、为什么不结束”三件事全部拿到实据，DDL 卡住时就不必靠重启数据库碰运气。