MySQL 在线 DDL 怎样判断操作是否会阻塞写入

MySQL 的“在线 DDL”不等于“完全不会阻塞写入”。判断一条 ALTER TABLE 是否会影响写入，要同时看它采用的算法、LOCK 级别，以及执行期间是否有长事务占着表的元数据锁。对 InnoDB 来说，最稳妥的做法是先用明确的 ALGORITHM 和 LOCK 约束能力，再用进程列表或 Performance Schema 观察真实等待。

先看 ALTER TABLE 选择了哪种算法

我在安排表结构变更时，第一眼不会只看“online”这个词，而是先判断数据是否需要重建。INSTANT 只改数据字典，表数据不动，通常允许并发 DML；INPLACE 不复制成一张新表，但可能在原表上重建，通常支持并发 DML；COPY 会把数据逐行复制到副本，不能允许并发 DML。

因此，下面这种写法表达的是“如果不能原地完成，就直接失败”，不会默默退回表复制：

-- 只接受原地变更；若当前操作不支持 INPLACE，就让语句失败。
ALTER TABLE orders
  ADD COLUMN source_code VARCHAR(32) NULL,
  ALGORITHM=INPLACE,
  LOCK=NONE;

注意，算法仍不是全部答案。即使使用 INPLACE，某些操作也会重建表；即使使用 INSTANT，更新表定义时仍可能短暂需要排他的元数据锁。若一条变更必须改写大量行，不能只凭“在线”二字估算窗口。

再用 LOCK 把写入要求写清楚

LOCK 可以把允许的并发程度写进语句。LOCK=NONE 要求读写都能并发；LOCK=SHARED 允许读但会阻塞写；LOCK=EXCLUSIVE 会阻塞读写；LOCK=DEFAULT 则让 MySQL 在当前算法和操作支持范围内选择尽可能高的并发。

这里的“直接报错”反而是好事：在生产环境中，与其让一次不兼容的 DDL 按默认策略运行，不如让它在变更前暴露能力不匹配。MySQL 官方文档也说明，指定不兼容的算法或锁级别时，语句会停止并返回错误。

为什么 LOCK=NONE 仍可能等写入

接下来最容易踩坑的地方是元数据锁。一个显式事务只执行了查询，却没有提交，仍可能一直持有该表的元数据锁。在线 DDL 在初始化阶段获取可升级的元数据锁，结束时更新表定义还需要排他的元数据锁；所以它可以在大部分时间允许 DML，却在最后的切换窗口等待长事务结束。

-- 事务中的查询会让元数据锁持续到 COMMIT 或 ROLLBACK。
START TRANSACTION;
SELECT id FROM orders WHERE id = 1001;

-- 另一个会话执行在线 DDL 时，最后的表定义切换可能等待上面的事务。
ALTER TABLE orders
  ADD COLUMN source_code VARCHAR(32) NULL,
  ALGORITHM=INPLACE,
  LOCK=NONE;

-- 业务确认不再使用事务后，释放元数据锁。
COMMIT;

这也是“在线 DDL 阻塞写入”经常看起来反直觉的原因：阻塞点可能不是重建表本身，而是 DDL 正在等待一个早已开始、却迟迟没有结束的事务；当 DDL 已经排队等待排他元数据锁时，后来的查询也可能排在它后面。

用 SHOW FULL PROCESSLIST 找到等待链

变更窗口中先看进程状态，重点找 Waiting for table metadata lock，不要只盯着 DDL 的总耗时：

-- FULL 让 Info 保留完整 SQL，便于确认是谁在等待哪张表。
SHOW FULL PROCESSLIST;

如果服务器启用了 Performance Schema，可以进一步查看 metadata_locks。其中 LOCK_STATUS='PENDING' 表示请求尚未拿到锁，GRANTED 表示当前持有锁；配合线程信息可以把“等待者”和“持有者”关联起来：

-- 只观察目标表的元数据锁；schema 和表名按实际对象替换。
SELECT OBJECT_SCHEMA, OBJECT_NAME, LOCK_TYPE,
       LOCK_DURATION, LOCK_STATUS, OWNER_THREAD_ID
FROM performance_schema.metadata_locks
WHERE OBJECT_TYPE = 'TABLE'
  AND OBJECT_SCHEMA = 'shop'
  AND OBJECT_NAME = 'orders';

排查结果通常分成两类：如果 DDL 是 PENDING，优先查哪个事务持有 GRANTED 的兼容锁；如果 DDL 已经获得锁但后续请求排队，则应先评估继续等待的影响，再决定取消 DDL 或让业务事务尽快结束。不要因为看到 LOCK=NONE 就跳过这一步。

上线前的五项判断

1. 确认表使用的存储引擎和具体 ALTER 操作，先判断是否支持 INSTANT 或 INPLACE。
2. 会改写数据或重建表时，按 COPY/INPLACE 的资源消耗估算磁盘、CPU、I/O 与在线日志空间。
3. 要求写入不中断时显式使用 LOCK=NONE，让能力不足变成可见错误。
4. 执行前清理长事务，执行中同时观察 DDL、元数据锁和业务写入队列。
5. 把最后的表定义切换当成独立风险点，预留能让持锁事务提交或回滚的窗口。

最后可以把判断收敛成一句话：算法决定 DDL 是否需要复制或重建，LOCK 决定可接受的并发下限，元数据锁决定它是否会在准备或收尾阶段等待。三者一起看，才知道“在线”到底能不能满足这次变更的写入要求。

相关问题

LOCK=NONE 会保证整个过程完全不阻塞吗？

不会。它要求支持的并发 DML，但初始化和最终更新表定义仍可能短暂争用元数据锁，长事务会让 DDL 等待。

什么时候应该拒绝使用默认算法？

当变更窗口不能接受表复制，或必须保证写入不中断时，显式指定可接受的算法和锁级别更稳妥；不支持就让语句失败，再重新安排方案。