MySQL Online DDL 是什么？ALGORITHM=INSTANT、INPLACE 和 COPY 有什么区别？

知识点详解：表结构改变，不只是改一行定义

加字段与加索引，不是同一类工作

假设要给一张持续写入的大表增加字段。某些版本、表条件和字段操作支持 INSTANT，主要更新相关元数据，不需要遍历整张表重写每行。

而增加一个需要构建内容的索引，通常要读取数据并建立新的索引结构。不能因为前一条 ALTER 很快，就认定后一条同样只是改个名字。

先到 MySQL 8.4 Online DDL 操作矩阵查具体操作，再结合表条件分析。矩阵比一句“支持在线”更有用。

三种算法不要只靠英文猜

INSTANT 的关键是支持范围内的即时元数据方式，但有操作和表条件限制。

INPLACE 这个名字很容易被翻译成“原地、不重建”。实际上，一些 INPLACE 操作仍会重建表。它与 COPY 的区别不能简化成“数据一动都不动”。

COPY 的复制过程通常需要更明显的空间与访问限制。具体能否并发读、写，仍然要看这次操作，而不是给三种算法各贴一个永久的锁标签。

ALGORITHM 与 LOCK 各表达什么？

算法回答“怎样做这个变更”；LOCK 回答“你允许怎样的并发访问”。两者组合不受支持时，应按数据库契约报错或采用符合显式要求的行为，不能假装已经满足。

在正式变更里，明确表达可接受要求有助于避免静默使用更昂贵的处理方式。但不是把 INSTANT、LOCK=NONE 随便组合，就能让原本不支持的操作成功。

这里不提供一条鼓励直接在生产执行的通用 SQL。DDL 需要跟具体表与版本一起审核。

图：算法与并发要求分开判断。

为什么长事务还能让 Online DDL 等待？

结构变更仍需要元数据锁。一个正在使用相关表、尚未结束的事务，可能让变更获取必要锁的过程等待。

在线执行的不同阶段，也可能有锁需求。等待队列还可能影响后面的请求。因此，“可以并发 DML”不等于从开始到结束都没有短暂阻塞，更不等于长事务完全无关。

图：长事务会让结构变更等待。

上线前至少准备哪些东西？

先确认数据量、剩余磁盘、变更算法与并发限制，再检查长事务和锁等待。测试里观察写入延迟、执行时间、资源占用与中断后的状态。

还要有明确的停止与回退安排。某些结构变更并不具备简单的一键逆操作，回退可能需要另外的迁移过程。不要只保存一条反向 ALTER 就认为恢复方案已经完成。

本文按官方矩阵解释，没有伪造真实大表测试结果。

面试官继续追问

INSTANT 一定适用加字段吗？

不是。版本、表格式、字段位置与其他限制都要查对应操作，不能把一个成功案例推广到所有表。

如何避免等待太久？

先排查长事务、设置合理的执行与锁等待策略，再安排受控窗口和监控。不是让 DDL 无限排队，等到线上请求全被拖住。

面试速记卡

• 在线：一定条件下可并发，不是完全无锁。
• INSTANT：支持范围内主要改变元数据。
• INPLACE：仍可能重建，不能照字面理解。
• ALGORITHM / LOCK：执行方式与并发要求分别判断。
• 验收：操作矩阵、MDL、长事务、磁盘和回退一起检查。