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_created_at(created_at), ALGORITHM=INPLACE;

这里有个关键点：INPLACE不一定等于Online！根据我的经验，大约30%的INPLACE操作仍会短暂锁表。比如删除主键这种操作，虽然用INPLACE但会阻塞写入。

性能方面，在MySQL 5.7上给亿级表加索引，INPLACE比COPY快60%。但要注意磁盘空间，虽然不需要双倍空间，但临时文件可能暴涨。有次我们给200GB的表加索引，临时文件一度涨到180GB，差点撑爆磁盘。

2.3 INSTANT算法：秒级变更的黑科技

INSTANT算法是MySQL 8.0的杀手锏，它的原理就像改户口本：

1. 只在数据字典里更新元数据
2. 不动实际数据文件
3. 整个过程只需毫秒级

sql复制-- INSTANT方式添加可空列
ALTER TABLE products ADD COLUMN discount DECIMAL(5,2) NULL, ALGORITHM=INSTANT;

但现实很骨感，目前INSTANT只支持有限操作：

• 添加可空列（非最后位置）
• 修改列默认值
• 重命名表等元数据操作

我在测试环境做过对比：同样添加可空列，INSTANT耗时0.01秒，INPLACE要28秒（100万行数据）。可惜生产环境大多还在用5.7，这个神器暂时难以普及。

3. 实战选型决策框架

3.1 四维评估法

根据多年踩坑经验，我总结出这个决策框架：

具体选型时，我通常会问四个问题：

1. 能接受多长停机时间？（业务容忍度）
2. 磁盘剩余空间够吗？（硬件限制）
3. 变更期间允许写入吗？（并发需求）
4. MySQL版本支持吗？（环境约束）

3.2 经典场景解决方案

场景一：电商大促前加字段

• 需求：用户表新增vip_level字段
• 约束：零停机、表数据量1亿+
• 方案：INPLACE + LOCK=NONE

sql复制ALTER TABLE users ADD COLUMN vip_level TINYINT DEFAULT 0, 
ALGORITHM=INPLACE, LOCK=NONE;

场景二：凌晨维护窗口改主键

• 需求：订单表修改主键字段
• 约束：允许2分钟不可用
• 方案：COPY + 维护时段执行

sql复制-- 提前通知停机维护
ALTER TABLE orders DROP PRIMARY KEY, ADD PRIMARY KEY(new_id), 
ALGORITHM=COPY;

场景三：SaaS产品动态扩展

• 需求：客户自定义字段
• 约束：多租户、要求实时生效
• 方案：MySQL 8.0 + INSTANT

sql复制-- 需要确认版本支持
ALTER TABLE tenant_data ADD COLUMN dynamic_field VARCHAR(255) NULL,
ALGORITHM=INSTANT;

4. 高阶技巧与避坑指南

4.1 监控与优化手段

执行Online DDL时，我习惯开三个窗口：

1. 主窗口执行ALTER
2. 监控进度：SHOW PROCESSLIST看State字段
3. 观察性能：SELECT * FROM sys.schema_table_lock_waits

对于大型表，这些参数可以优化速度：

sql复制-- 调整排序缓冲区
SET SESSION sort_buffer_size = 64*1024*1024;
-- 增加并行线程
SET SESSION innodb_online_alter_log_max_size = 512*1024*1024;

4.2 常见报错处理

错误1："Lock wait timeout exceeded"

• 原因：有其他长事务持有MDL锁
• 解决：SHOW ENGINE INNODB STATUS查阻塞源

错误2："Duplicate entry for key"

• 原因：Online DDL期间唯一键冲突
• 解决：先删除唯一约束，变更完再加回来

错误3："Disk is full"

• 预防：确保剩余空间 > 表大小的1.5倍
• 应急：立即KILL DDL进程释放空间

4.3 第三方工具选型

当原生Online DDL不能满足时，我会考虑：

• gh-ost：适合需要精细控制的大表变更

  bash复制gh-ost \
  --host="127.0.0.1" \
  --database="test" \
  --table="big_table" \
  --alter="ADD COLUMN remark TEXT" \
  --execute
  

• pt-online-schema-change：适合需要触发器的场景

  bash复制pt-online-schema-change \
  --alter "ADD COLUMN status TINYINT(1)" \
  D=test,t=users \
  --execute
  

工具对比：

• gh-ost：不用触发器、更低的主库负载
• pt-osc：兼容性更好、支持更复杂变更

5. 版本升级带来的变化

MySQL 5.6到8.0的Online DDL进化令人惊艳：

• 5.6：基础INPLACE支持，仅限添加索引等简单操作
• 5.7：支持更多操作类型，缩短锁持有时间
• 8.0：引入INSTANT算法，元数据操作秒级完成

有个有趣的发现：8.0.23之后，添加自增列也支持INPLACE了。之前这类操作必须用COPY算法，现在可以这样优雅处理：

sql复制ALTER TABLE logs ADD COLUMN id BIGINT AUTO_INCREMENT PRIMARY KEY,
ALGORITHM=INPLACE;

不过要注意版本差异，我有次在5.7执行8.0才支持的语法，直接导致复制中断。现在执行任何DDL前，都会先用SELECT @@version确认版本特性。