MySQL在线DDL降低表变更影响

线上表变更最怕的不是 ALTER TABLE 语句本身，而是没有先确认它会采用哪种算法、需要什么锁。生产环境的稳妥做法是：优先让支持的操作使用 ALGORITHM=INSTANT；需要重建但允许并发写入时再考虑 ALGORITHM=INPLACE；对无法满足条件的操作不要默认退回 COPY，而是让它先失败并重新安排窗口。MySQL 在线 DDL 能降低影响，但不能消除元数据锁和磁盘资源风险。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/

先把在线 DDL 的边界说清楚

“在线”描述的是变更期间允许的并发程度，不等于整个语句从头到尾都不会等待。INSTANT 主要修改数据字典，数据页不需要重写；INPLACE 避免传统表复制，但某些操作仍会重建表；COPY 则在新表上复制原表数据，通常不适合繁忙写入表。

因此，不能只看到“加列”就认定一定瞬时完成。表是否为 InnoDB、列定义、行格式、全文索引、临时表以及历史 instant 变更次数都会影响能力。把算法写进语句，是在发布前锁定预期边界：

ALTER TABLE orders
  ADD COLUMN risk_level TINYINT NOT NULL DEFAULT 0,
  ALGORITHM=INSTANT;
-- 只允许元数据级加列；不满足 INSTANT 条件时直接失败

选择算法与锁级别

对需要重建或创建索引的操作，LOCK=NONE 可以表达“尽量允许并发读写”的要求；LOCK=SHARED 表示允许读但限制写；LOCK=EXCLUSIVE 则把完成速度放在并发之上。若指定的并发级别不被该操作支持，语句应立即失败，这比静默采用更重的锁更容易控制风险。

例如新增二级索引时，可以把预期写成：

ALTER TABLE orders
  ADD INDEX idx_customer_created (customer_id, created_at),
  ALGORITHM=INPLACE,
  LOCK=NONE;
-- 目标是在线建索引；若实例或表条件不支持，语句应失败而不是放宽锁级别

这不是性能保证。建索引仍会消耗 CPU、I/O 和临时空间，持续写入还会增加在线变更日志压力。LOCK=NONE 只约束并发访问边界，不会替你估算完成时间。

把元数据锁放进发布前检查

在线 DDL 在初始化和收尾阶段仍要取得元数据锁。一个长事务即使只执行过一次查询，也可能把锁保留到事务提交；DDL 等待期间，后续会话还可能因为锁请求排队而受到影响。

发布前先看事务和会话，再决定是否执行，而不是把排障留给业务报警：

SELECT trx_mysql_thread_id, trx_started, trx_query
FROM information_schema.innodb_trx
WHERE trx_started IS NOT NULL;
-- 先找持续时间异常的事务，确认其是否访问目标表

SHOW FULL PROCESSLIST;
-- 关注 Waiting for table metadata lock 等等待状态

检查结果不应只看“当前没有等待”。还要确认没有长事务即将持有目标表，外键关联表没有被另一条 DDL 占用，并为等待时间设置停止条件。必要时让业务连接池先降载，再执行变更。

把资源和失败条件写进发布清单

对修改列类型、收缩 VARCHAR 或其他不支持瞬时/原地处理的变更，要把它视为重建类发布：预估数据量、准备足够空间、设置业务低峰，并明确失败后的恢复路径。不要因为语句带了 LOCK=NONE 就跳过容量评估。

一份可复用的上线判断

可以把变更记录成五列：变更动作、目标算法、目标锁级别、主要资源、停止条件。只有当算法和锁级别都能被实例接受，且长事务与空间检查通过，才进入执行窗口。执行后观察 DDL 会话、业务延迟、错误率和磁盘变化；一旦等待锁或资源消耗超过预设阈值，停止后续变更，不要在同一窗口连续追加 ALTER。

常见问题

指定 ALGORITHM=INSTANT 失败，能否直接改成 INPLACE？

可以，但先确认这次变更是否允许重建、是否有足够空间和发布时间。不要把降级当作自动重试；它改变了资源和锁风险。

LOCK=NONE 是否代表完全不会阻塞？

不是。它约束在线阶段的并发目标，初始化和收尾仍可能等待元数据锁，长事务也可能让后续会话排队。

为什么小表也要做在线 DDL 检查？

表大小只影响数据处理成本，不能消除锁依赖、外键关系、行格式限制和临时空间问题。小表同样可能因为一个未提交事务卡住收尾。