MySQL DDL 卡在 metadata lock 怎么找阻塞会话

MySQL 的 DDL 如果长期停在 Waiting for table metadata lock，最直接的办法是先查 sys.schema_table_lock_waits：它会同时列出等待会话的 waiting_pid、阻塞会话的 blocking_pid、双方语句以及候选的 KILL 命令。随后再用 performance_schema.metadata_locks 与 performance_schema.threads 核对锁对象、锁状态和连接详情。

我处理这类问题时，不会看到阻塞 PID 就立刻终止连接。更稳妥的顺序是“确认等待对象—确认持锁会话—确认未提交事务—评估回滚影响—再决定提交、回滚或终止”。metadata lock 保护的是对象定义一致性，一个看似空闲的连接也可能因为事务没有结束而继续持锁。

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

为什么DDL会被一个看似空闲的会话挡住

MySQL 会对事务使用过的表持有元数据锁，并把释放时间推迟到事务结束。因此，另一个会话要执行 ALTER TABLE、DROP TABLE 或其他需要更强MDL的操作时，就可能等待前一个事务提交或回滚。自动提交模式下，一条语句本身就是完整事务，锁一般在语句结束时释放；显式事务则可能跨越多条语句。

这也解释了一个常见误判：阻塞连接在进程列表里可能显示为 Sleep，但它此前已经访问过目标表且事务还没结束。当前没有正在运行的SQL，不等于当前没有持有事务级元数据锁。

先用sys视图直接找到等待与阻塞双方

MySQL 8.0/8.4 的 sys.schema_table_lock_waits 已经把底层锁记录整理成等待方与阻塞方的配对结果。排障时先执行下面的只读查询，通常比手工拼接多张 Performance Schema 表更快。

-- 先查看所有正在等待表级元数据锁的会话，以及对应阻塞方
SELECT
    object_schema,
    object_name,
    waiting_pid,
    waiting_account,
    waiting_lock_type,
    waiting_query_secs,
    waiting_query,
    blocking_pid,
    blocking_account,
    blocking_lock_type,
    blocking_lock_duration,
    sql_kill_blocking_query,
    sql_kill_blocking_connection
FROM sys.schema_table_lock_waits
ORDER BY waiting_query_secs DESC;

先看 object_schema 与 object_name 是否就是DDL目标，再看 waiting_query 是否为当前变更语句。确认后，blocking_pid 才是需要继续调查的连接编号。视图返回的两个KILL字段只是候选语句，不是建议立即执行。

用metadata_locks核对底层锁记录

如果sys视图不存在、权限受限，或者你想确认锁类型与持续范围，可以直接查 performance_schema.metadata_locks。其中 PENDING 表示请求尚未获得，GRANTED 表示当前已授予；OWNER_THREAD_ID 可与 performance_schema.threads.THREAD_ID 关联，从而找到进程列表ID。

-- 把库名和表名替换成DDL实际操作的对象
SELECT
    ml.OBJECT_SCHEMA,
    ml.OBJECT_NAME,
    ml.LOCK_TYPE,
    ml.LOCK_DURATION,
    ml.LOCK_STATUS,
    ml.OWNER_THREAD_ID,
    t.PROCESSLIST_ID AS processlist_id,
    t.PROCESSLIST_USER,
    t.PROCESSLIST_HOST,
    t.PROCESSLIST_DB,
    t.PROCESSLIST_COMMAND,
    t.PROCESSLIST_TIME,
    t.PROCESSLIST_STATE,
    t.PROCESSLIST_INFO
FROM performance_schema.metadata_locks AS ml
LEFT JOIN performance_schema.threads AS t
       ON t.THREAD_ID = ml.OWNER_THREAD_ID
WHERE ml.OBJECT_TYPE = 'TABLE'
  AND ml.OBJECT_SCHEMA = 'app_db'  -- 目标库
  AND ml.OBJECT_NAME = 'orders'    -- 目标表
ORDER BY
    CASE ml.LOCK_STATUS WHEN 'PENDING' THEN 0 ELSE 1 END,
    t.PROCESSLIST_TIME DESC;

这里的 GRANTED 行是持锁候选，并不意味着同一对象上的每一条GRANTED记录都必然直接阻塞DDL，所以我仍会优先参考sys视图给出的配对关系，再把底层表用于核对。若 metadata_locks 没有数据，可检查 wait/lock/metadata/sql/mdl instrument 是否启用；MySQL 8.4官方手册说明它默认启用。

确认阻塞会话是否带着未提交事务

拿到 blocking_pid 后，下一步不是立即KILL，而是看这个连接属于谁、事务从何时开始、当前是否仍有活跃语句。下面把进程列表线程与InnoDB事务做一次左连接；即使连接处于Sleep，也能看到是否存在对应事务。

-- 将12345替换为sys视图返回的blocking_pid
SELECT
    t.PROCESSLIST_ID,
    t.PROCESSLIST_USER,
    t.PROCESSLIST_HOST,
    t.PROCESSLIST_DB,
    t.PROCESSLIST_COMMAND,
    t.PROCESSLIST_TIME,
    t.PROCESSLIST_STATE,
    t.PROCESSLIST_INFO,
    trx.TRX_ID,
    trx.TRX_STARTED,
    trx.TRX_STATE,
    trx.TRX_ROWS_MODIFIED
FROM performance_schema.threads AS t
LEFT JOIN information_schema.innodb_trx AS trx
       ON trx.TRX_MYSQL_THREAD_ID = t.PROCESSLIST_ID
WHERE t.PROCESSLIST_ID = 12345;

如果能联系到应用或任务的负责人，优先在原连接中正常 COMMIT 或 ROLLBACK。这样业务方能确认事务语义，也能避免突然断开带来的大事务回滚。若连接属于批处理、迁移工具或手工窗口，还应先确认它是否会自动重连并再次开启同样的事务。

什么时候才考虑KILL

KILL QUERY 终止当前语句，KILL CONNECTION 会结束连接；连接中存在活动事务时，断开会触发回滚。对于“Sleep但事务未结束”的阻塞连接，单纯终止查询往往无济于事，因为当前已经没有查询可终止，此时若确实得到业务授权，才可能需要终止连接。

-- 示例只展示语法；执行前必须确认PID、业务归属和回滚影响
KILL QUERY 12345;

-- 仅在确认可以断开连接并接受事务回滚时使用
KILL CONNECTION 12345;

我的取舍是：只读诊断可以立即做，提交或回滚交给事务所有者，终止连接则需要明确授权。尤其是修改行数很多的事务，KILL之后的回滚也可能持续较长时间，DDL并不一定马上恢复。

最小复查：等待消失且DDL继续

处理完成后，再查一次sys视图和底层锁表。目标对象不应再出现等待行，原DDL会话也应离开metadata lock等待状态。不要通过重复提交同一条DDL来“测试”，否则可能制造新的等待者。

-- 目标对象不再返回记录，表示sys视图中已没有对应等待关系
SELECT object_schema, object_name, waiting_pid, blocking_pid
FROM sys.schema_table_lock_waits
WHERE object_schema = 'app_db'
  AND object_name = 'orders';

-- 底层表中不应再有目标对象的PENDING锁请求
SELECT OBJECT_SCHEMA, OBJECT_NAME, LOCK_TYPE, LOCK_STATUS, OWNER_THREAD_ID
FROM performance_schema.metadata_locks
WHERE OBJECT_TYPE = 'TABLE'
  AND OBJECT_SCHEMA = 'app_db'
  AND OBJECT_NAME = 'orders'
  AND LOCK_STATUS = 'PENDING';

以后怎么减少同类阻塞

• DDL前先检查目标库是否存在长事务，尤其是Sleep但未提交的应用连接。
• 把变更放在低峰期，并让发布系统为锁等待设置可控的失败边界，避免无限挂起。
• 缩短应用事务范围，不要在事务中夹杂外部接口调用、人工等待或长时间计算。
• 将等待PID、阻塞PID、对象名和事务开始时间纳入变更前检查记录，方便责任方快速确认。

相关问题

data_lock_waits能直接查metadata lock吗？

不能把两者混为一谈。data_lock_waits 面向数据锁等待，而本文讨论的是元数据锁；定位DDL卡住应优先使用 metadata_locks 或 sys.schema_table_lock_waits。

SHOW PROCESSLIST为什么只看到DDL在等？

因为持锁会话可能处于Sleep，单看当前语句不容易看出它与目标表的锁关系。Performance Schema的锁记录与线程映射能补上这层关联。

把lock_wait_timeout调小能解决根因吗？

它只能让等待更快失败，不能释放别的事务持有的MDL。根因仍然是阻塞事务没有结束，或者变更窗口内存在持续访问和长事务。