在掘金看到一篇文章,讲的是千万级订单表如何新增字段,里面介绍了一些方法,我正好学习了一下,同时结合ai的回答,整理成一篇博客,记录一下操作指南。
针对千万级订单表新增字段,需要综合考虑业务连续性、锁表风险、数据一致性、回滚方案等因素。以下是分场景的详细方案:
1. 低峰期+短时间停机(最稳妥)
适用场景 :可接受分钟级停机(如凌晨低峰期)。
步骤:
-
备份:提前全量备份(物理备份+Binlog)。
-
停机:断开应用连接(如改域名、停止服务)。
-
DDL直接执行 :
sqlALTER TABLE orders ADD COLUMN new_col VARCHAR(50) DEFAULT NULL, ALGORITHM=INPLACE, LOCK=NONE;- MySQL 5.6+ :若满足
INPLACE条件(如无全文索引、触发器等),可LOCK=NONE避免锁表。 - MySQL 8.0 :支持
INSTANT算法(仅修改元数据,秒级完成),但限制较多(如不能是NOT NULL、不能有默认值)。
- MySQL 5.6+ :若满足
-
验证:检查表结构、数据一致性(如采样对比)。
-
恢复服务:逐步放开流量。
2. 在线DDL(无停机,但需权衡风险)
适用场景 :无法停机,且表为InnoDB、MySQL 5.6+。
关键参数:
ALGORITHM=INPLACE:避免重建表(需满足条件,如无触发器、外键等)。LOCK=NONE:允许并发读写(若不支持会降级为SHARED或EXCLUSIVE)。old_alter_table=OFF:强制使用新算法(MySQL 5.6+默认)。
风险:
- 大表可能触发IO/CPU飙升 (监控
InnoDB_history_list_length、磁盘IO)。 - 长时间锁等待 :若存在长事务(如
SHOW PROCESSLIST中Waiting for table metadata lock),需先 kill 长事务。
优化:
- 分批操作 :若需
NOT NULL+默认值,可分两步:-
先加 nullable 字段:
sqlALTER TABLE orders ADD COLUMN new_col VARCHAR(50) NULL, ALGORITHM=INPLACE, LOCK=NONE; -
后续用
UPDATE分批写默认值(如按ID区间分批,避免一次性全表更新)。 -
最后改
NOT NULL(需确保无NULL值):sqlALTER TABLE orders MODIFY COLUMN new_col VARCHAR(50) NOT NULL, ALGORITHM=INPLACE, LOCK=NONE;
-
3. 影子表切换(零停机,复杂度高)
适用场景 :表极大(如亿级)、DDL不可接受,或需添加复杂约束 (如外键、全文索引)。
步骤:
-
创建影子表 :
sqlCREATE TABLE orders_new LIKE orders; ALTER TABLE orders_new ADD COLUMN new_col VARCHAR(50) DEFAULT NULL; -
同步数据 :
- 全量同步 :
INSERT INTO orders_new SELECT * FROM orders(需分批,避免锁表)。 - 增量同步 :用
Binlog或触发器同步增量数据(如Canal、Maxwell)。
- 全量同步 :
-
切换表名 :
sqlRENAME TABLE orders TO orders_old, orders_new TO orders;- 原子操作:MySQL会持有全局锁,但时间极短(毫秒级)。
-
清理:验证后删除旧表(延迟几天,确保无回滚需求)。
**4. 拓展表,按需关联查询 **
可以使用拓展表的方案
diff
order_extend
- order_id
- extra_field_x
- extra_field_y
原表不动,有新字段时写入到拓展表里,业务查询时做join。 需要查询麻烦点,但优点是:
- 主表结果稳定
- 拓展字段可动态管理
- 不影响现有业务逻辑
**5. 高级玩法:JSON拓展字段 **
定义一个ext字段,类型为TEXT或JSON,所有新增字段都放在里面去,用规则解析。这个方法是目前工作中,我们常用的方法
arduino
{
""topic": "",
"idkp": ""
}
这样一来,以后有新字段就塞进去,不用再修改表结构,非常灵活。叫做schema-less 拓展结构。
6. 其他关键细节
- 默认值处理 :
- MySQL 5.6+ :
ALGORITHM=INPLACE不支持NOT NULL+默认值(会重建表),需用影子表或分批更新。 - MySQL 8.0 :支持
INSTANT算法加NOT NULL+默认值(仅限非VARCHAR变长字段)。
- MySQL 5.6+ :
- 磁盘空间 :
INPLACE算法需额外排序缓冲区(约等于表大小),确保磁盘剩余空间>表大小×2。
- 回滚方案 :
- 提前验证
DDL是否可逆(如DROP COLUMN会立即释放空间,无法回滚)。 - 保留备份+Binlog,必要时可基于时间点恢复。
- 提前验证
总结选择
| 场景 | 推荐方案 | 耗时 | 风险 |
|---|---|---|---|
| 可停机 | 低峰期直接DDL | 分钟级 | 低 |
| 不可停机+简单字段 | 在线DDL(INPLACE) | 分钟到小时 | 中(监控锁等待) |
| 不可停机+复杂字段 | 影子表切换 | 小时到天数 | 高(需同步工具) |
| 拓展表,按需关联查询 | |||
| JSON拓展字段 |
最终建议:
- 优先测试 :在测试库用
ALTER TABLE ... ALGORITHM=INPLACE, LOCK=NONE验证是否支持在线DDL。 - 监控 :执行时实时监控
SHOW PROCESSLIST、磁盘IO、长事务。 - 兜底:备份+影子表方案备用,确保可随时切换。