Online DDL实战：如何选择最适合你的表结构变更方案？

1. Online DDL的前世今生

第一次接触Online DDL是在五年前的一个深夜，当时我们生产环境的用户表需要新增一个字段，执行ALTER TABLE后整个数据库连接池瞬间爆满，前端页面直接报错。那次事故让我深刻意识到传统DDL操作的致命缺陷——它会锁表阻塞所有读写请求。

Online DDL的出现彻底改变了这种局面。简单来说，它允许我们在不锁表或短暂锁表的情况下完成表结构变更。想象一下给行驶中的汽车更换轮胎，这就是Online DDL的神奇之处。MySQL从5.6版本开始引入这项技术，经过5.7的完善，到8.0已经发展出三种成熟的算法：COPY、INPLACE和INSTANT。

这三种算法就像装修房子的三种方案：COPY相当于另建新房再搬家（最稳妥但耗时），INPLACE类似原地翻修（平衡方案），INSTANT则是换个门牌号就完事（最快但限制多）。作为DBA，我们需要根据业务场景选择最合适的"装修方案"。

2. 三大算法原理深度拆解

2.1 COPY算法：最传统的改造方案

COPY算法的工作流程就像搬家：

1. 先在隔壁空地上按新图纸建房子（创建临时表）
2. 把旧家具一件件搬过去（逐行拷贝数据）
3. 拆掉旧房子（删除原表）
4. 把新房子门牌换成旧的（重命名）

sql复制-- 典型COPY算法操作示例
ALTER TABLE users ADD COLUMN age INT, ALGORITHM=COPY;

这个过程中最耗时的就是第二步数据拷贝。我做过测试，一张500万行的表添加字段，COPY算法耗时是INPLACE的3倍。而且需要双倍存储空间，这在磁盘紧张的服务器上简直是灾难。

但它的优势是兼容性最好，所有MySQL版本都支持，适合小型表或需要复杂变更的场景。去年我们给金融系统做字段类型变更（VARCHAR转BIGINT），就只有COPY算法能保证数据绝对安全。

2.2 INPLACE算法：平衡的艺术

INPLACE算法就像老房改造：

1. 先搭个脚手架（创建临时文件）
2. 边装修边记录住户需求（row log记录DML）
3. 最后快速切换（提交阶段锁表重放日志）

sql复制-- INPLACE算法添加索引
ALTER TABLE orders ADD INDEX idx_cre