MySQL metadata_locks 怎么定位 DDL 卡住：等待对象、持有者与解除前检查

线上给订单表加一列时，DDL 长时间停在等待状态，通常不是“ALTER 语句写错了”，而是某个仍未结束的事务持有表级元数据锁。定位这类问题，先看 performance_schema.metadata_locks 中谁在等待、谁已经持有，再把对象和线程映射回会话，确认业务影响后才处理阻塞者。

下面用 shop.orders 作为示例表。查询只读 Performance Schema 和 sys 视图，不会自动杀会话；示例中的进程号是占位数据，生产环境要替换成现场查询结果。

先把“DDL 卡住”分成等待者和持有者

元数据锁保护表定义及相关对象。一个连接请求 DDL 时，如果另一个连接还在事务里访问同一张表，DDL 可能停在等待。第一步不要急着执行 KILL，先确认 Performance Schema 的元数据锁信息是否可见：

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

LOCK_STATUS = 'PENDING' 表示请求还没拿到锁，GRANTED 表示已经持有。把这两类行按同一个 OBJECT_SCHEMA、OBJECT_NAME 和锁类型对照，才能知道 DDL 是在等哪一项，而不是把所有“运行很久”的连接都当成根因。

用对象字段确认没有查错表

排查脚本最容易出现的误判，是只按进程号筛选，忽略同一会话可能已经切换到别的语句。元数据锁记录中的 OBJECT_TYPE、OBJECT_SCHEMA 和 OBJECT_NAME 要一起核对，尤其是同名表存在于多个 schema 时。

SELECT OBJECT_TYPE,
       OBJECT_SCHEMA,
       OBJECT_NAME,
       LOCK_TYPE,
       LOCK_DURATION,
       LOCK_STATUS
FROM performance_schema.metadata_locks
WHERE LOCK_STATUS = 'PENDING'
ORDER BY OBJECT_SCHEMA, OBJECT_NAME;

如果结果指向 shop.orders，再回看 DDL 的目标是否也是这个对象；如果是视图、存储程序或其他对象，则不能套用“表被一个长事务占用”的结论。这里的控制流很简单：先筛等待行，再确认对象，再找对应线程。

把 OWNER_THREAD_ID 映射回真正的会话

metadata_locks 里的 OWNER_THREAD_ID 是 Performance Schema 线程标识，不一定等于客户端看到的进程号。用 performance_schema.threads 把它映射到 PROCESSLIST_ID，再查看用户、主机和当前语句：

SELECT m.OBJECT_SCHEMA,
       m.OBJECT_NAME,
       m.LOCK_STATUS,
       m.OWNER_THREAD_ID,
       t.PROCESSLIST_ID,
       t.PROCESSLIST_USER,
       t.PROCESSLIST_HOST,
       t.PROCESSLIST_COMMAND,
       t.PROCESSLIST_INFO
FROM performance_schema.metadata_locks AS m
JOIN performance_schema.threads AS t
  ON t.THREAD_ID = m.OWNER_THREAD_ID
WHERE m.OBJECT_SCHEMA = 'shop'
  AND m.OBJECT_NAME = 'orders';

重点看 PROCESSLIST_ID、PROCESSLIST_COMMAND 和 PROCESSLIST_INFO：前者才是后续会话管理命令通常使用的连接标识，后两者帮助判断它是空闲事务、普通查询还是正在执行 DDL。若没有权限看到其他用户线程，先补齐观察权限，否则“没有阻塞者”可能只是可见性不足。

用 sys 视图快速看等待者和持有者

如果服务器已安装 sys schema，可以先查询 sys.schema_table_lock_waits。这个视图把等待者与阻塞者的线程和进程号整理在一行，适合值班时快速建立关系：

SELECT object_schema,
       object_name,
       waiting_pid,
       waiting_query,
       blocking_pid,
       blocking_query
FROM sys.schema_table_lock_waits
WHERE object_schema = 'shop'
  AND object_name = 'orders';

图中的关系是“等待者请求锁 → 持有者占用锁”。waiting_pid 对应卡住的 DDL，blocking_pid 对应当前持有资源的会话；但视图只帮你缩短定位路径，不能代替对事务状态、回滚时间和发布窗口的判断。

解除前先确认回滚和业务影响

确认阻塞者后，先执行只读检查，补看事务开始时间和最后活动时间，再决定让业务方提交、回滚或在窗口内终止连接。不要因为 blocking_pid 数字小就直接处理，也不要把等待者误杀成根因。

SELECT trx_mysql_thread_id,
       trx_started,
       trx_state,
       trx_query
FROM information_schema.innodb_trx
WHERE trx_mysql_thread_id IN (12345, 12346);  -- 用现场 pid 替换

如果阻塞者属于明确的长事务，优先让原连接正常结束；若必须终止，记录 blocking_pid、执行时间和业务确认信息，并预留回滚耗时。DDL 解除等待后还要重新检查目标表定义和应用错误日志，确认变更真正完成，而不是只看到连接消失。

常见问题

为什么 SHOW PROCESSLIST 看不到元数据锁关系？

进程列表主要告诉你会话正在做什么，不会像 metadata_locks 或 schema_table_lock_waits 那样直接列出锁对象和等待关系。两者应配合使用。

PENDING 行就是一定会导致 DDL 超时吗？

不一定。它说明当前请求尚未获得锁，是否超时取决于持有者何时释放、等待超时配置以及其他排队请求。先确认对象和会话。

可以直接 KILL blocking_pid 吗？

只有在确认会话归属、事务影响和回滚代价后才考虑。能正常提交或回滚时，通常比盲目终止更容易控制影响。

为什么查询不到 metadata_locks？

检查 Performance Schema 是否启用、元数据锁 instrument 是否可用，以及当前账号是否有足够观察权限。查询不到不等于没有锁。

收尾检查

一轮可靠的判断顺序是：先从 metadata_locks 找到 PENDING 和 GRANTED，再用 OBJECT_SCHEMA、OBJECT_NAME 确认对象，用 OWNER_THREAD_ID 映射会话，最后用 waiting_pid 和 blocking_pid 复核阻塞关系及事务代价。只有这些证据一致，解除动作才有依据。