MySQL 在线 DDL 怎样评估元数据锁风险

“在线 DDL”不等于“完全不加锁”。生产环境最容易被忽略的是元数据锁（MDL）：一个已经结束业务逻辑、却迟迟没有提交的事务，可能仍然持有表级元数据锁，让后续 ALTER TABLE 排队。评估风险的关键不是只看表有多少行，而是变更前确认谁在持锁、谁在等待，以及这次 ALTER 是否支持目标并发级别。

先判断：在线执行也会卡在元数据锁

MySQL 会为访问的表维护元数据锁，事务没有结束时，锁的释放可能被推迟到提交或回滚。于是即使 InnoDB 的表重建过程允许并发读写，DDL 仍可能在申请开始阶段的 MDL 时等待。外部表现通常是 ALTER 长时间没有进度，业务查询也可能在随后出现排队。

LOCK=NONE 的含义是：如果这项 ALTER 支持该并发级别，就允许并发读写；不支持时直接报错。它是“不要悄悄降级”的约束，不是跳过 MDL 的开关。表结构、操作类型、存储引擎和版本都要纳入评估。

第一步：先找出谁在等、谁在挡

如果启用了 sys Schema，优先查询等待关系。下面的 SQL 只读当前锁等待，不会主动杀连接；示例中的库名和表名请替换成目标对象。

-- 先看等待者、阻塞者和等待时长，再决定是否中止变更
SELECT object_schema,
       object_name,
       waiting_pid,
       waiting_query_secs,
       waiting_query,
       blocking_pid,
       blocking_lock_type,
       blocking_lock_duration,
       sql_kill_blocking_query
FROM sys.schema_table_lock_waits
WHERE object_schema = 'app'
  AND object_name = 'orders'
ORDER BY waiting_query_secs DESC;

重点看三列：waiting_query 是否就是本次 ALTER，blocking_pid 是否属于长期事务，以及 blocking_lock_duration 是否为事务级持有。官方 sys 视图同时列出 waiting 和 blocking 会话，并提供生成 KILL 语句的字段，但执行 KILL 前必须确认连接归属和业务影响。

第二步：用 metadata_locks 交叉确认锁状态

sys 视图适合直接定位等待链；需要核对锁类型和线程归属时，再查 Performance Schema。PENDING 表示请求还没有拿到锁，GRANTED 表示已经授予；行在锁释放后会被删除，所以这是瞬时观察结果。

-- 用线程 ID 和锁状态确认目标表当前的 MDL 记录
SELECT OBJECT_SCHEMA,
       OBJECT_NAME,
       LOCK_TYPE,
       LOCK_DURATION,
       LOCK_STATUS,
       OWNER_THREAD_ID,
       OWNER_EVENT_ID
FROM performance_schema.metadata_locks
WHERE OBJECT_TYPE = 'TABLE'
  AND OBJECT_SCHEMA = 'app'
  AND OBJECT_NAME = 'orders'
ORDER BY LOCK_STATUS, OWNER_THREAD_ID;

如果查询不到记录，不代表历史上没有锁：锁释放后行会消失，也可能是目标表名或 Performance Schema 过滤条件不准确。可以再用线程 ID 关联进程列表，核实连接的用户、来源和当前 SQL。生产排障中应保留一次采样结果，不要只凭一次空结果判定“没有风险”。

第三步：把等待时间和 DDL 能力写进变更方案

建议先在专用会话设置失败边界，再执行明确约束的 ALTER。lock_wait_timeout 控制获取元数据锁的等待秒数；它不是整个 DDL 的总执行时限，一条语句申请多个锁时，累计等待可能超过单次设置值。

-- 只限制当前变更会话，避免把全局默认值改成不可控的短超时
SET SESSION lock_wait_timeout = 5;

-- 仅当该操作支持 INPLACE 和 NONE 时才继续，否则立即报错
ALTER TABLE app.orders
  ADD INDEX idx_orders_created_at (created_at),
  ALGORITHM=INPLACE,
  LOCK=NONE;

这里的 5 秒只是示例，不是通用阈值：高峰期、复制链路和业务重试策略都可能需要更长窗口。变更前先在同版本、同表结构的环境确认算法能力；变更中观察等待关系；失败后优先处理持锁事务，不要把 LOCK=EXCLUSIVE 当成“更稳定”的默认选择。

执行后的检查清单：别把锁等待误判成重建耗时

最稳妥的流程是：低峰前采集一次锁等待、确认长事务和回滚能力；执行会话使用明确的算法与锁级别；执行中持续观察；结束后记录实际等待时间、执行时间和失败原因。这样评估的是可控风险，而不是笼统地把“在线”当作无锁。

常见问题

在线 DDL 会不会完全不阻塞业务查询？

不会保证。部分操作支持并发读写，但申请和释放元数据锁的阶段仍可能等待，具体能力取决于操作和表结构。

为什么 metadata_locks 查不到刚才的阻塞？

锁释放后记录会删除，或者查询筛选的库表、对象类型不匹配。用 sys 视图和进程列表交叉确认，并保留采样时间。

可以直接 KILL blocking_pid 吗？

先确认它是否为可安全终止的业务连接；优先让应用提交或回滚长事务，只有明确评估影响后才执行生成的 KILL 语句。

参考资料：https://dev.mysql.com/doc/refman/8.4/en/metadata-locking.html、https://dev.mysql.com/doc/refman/8.4/en/innodb-online-ddl.html、https://dev.mysql.com/doc/refman/8.4/en/performance-schema-metadata-locks-table.html、https://dev.mysql.com/doc/refman/8.4/en/sys-schema-table-lock-waits.html