MySQL 千万级表变更字段,要想不锁表,可以这么做!

B站影视 欧美电影 2025-09-07 15:53 4

摘要:最近我们遇到了一个看似简单但背后很有坑的需求:在千万级订单表中新增一个业务字段。需求来自隔壁项目组,他们需要这个字段做一些统计分析。

01

故事背景

最近我们遇到了一个看似简单但背后很有坑的需求:在千万级订单表中新增一个业务字段。需求来自隔壁项目组,他们需要这个字段做一些统计分析。

从开发角度看,这事很常见,新增字段嘛,直接 ALTER TABLE 加一下不就行了?但问题是——订单表是线上核心表,千万级数据,直接执行 DDL 语句极有可能锁表,影响线上业务运行,后果严重。

于是问题就来了:在不影响线上业务的前提下,怎么给千万级订单表加字段?

02

DDL 操作会锁表,线上执行慎之又慎

我们最初考虑的方案是直接在主库执行:

ALTER TABLEorderADDCOLUMN new_field VARCHAR(255);

理论上只是一条 SQL,但我们知道在 MySQL(尤其是老版本)中执行 DDL 是会锁表的。哪怕是短时间,也可能引发业务请求阻塞,造成雪崩。

于是我去问了一下朋友有没有好的经验,他说他们之前遇到类似的场景,采用的是主从切换方案:

03

主从切换方案:从库加字段,再主从切换

朋友的思路是这样的:

• 主库继续执行业务;

从库上执行 ALTER TABLE 新增字段;

• 执行完之后,把从库提升为主库;

• 再对原主库做一样的操作,恢复原来的主从关系。

这个方案理论上可行,而且对业务影响最小。但问题也很多:

• 切主从需要谨慎操作,搞不好数据有延迟或丢失;

• 要确保从库是只读的,否则可能数据不一致;

• 运维成本高,风险也高,不太适合小团队自己操作。

我心里想,这也太麻烦了吧。

04

在线 DDL 方案:背后其实很复杂

网上也有不少人提到可以用“在线 DDL”工具,比如 pt-online-schema-change 或 MySQL 8 的 INSTANT 选项。

深入了解后我才知道:

在线 DDL 其实是借助“创建一个新表 + 复制数据 + 写触发器 + 表名切换”来实现的。

简而言之,它不是对原表直接操作,而是旁边新建一个影子表,把旧表数据同步到新表里,然后在“合适时间”切换表名。

听起来更像是黑魔法了。而且,这种方案也需要评估触发器带来的写入延迟,表结构切换的时机控制也很重要。

我开始意识到,搞数据结构改动,本质就是一场战斗,要考虑的不仅仅是“能不能改”,而是“如何优雅不出事地改”。

05

转变思路:你真的需要这个字段入库吗?

我实在头疼,就去找产品经理聊聊。

我说:“订单表千万级数据量加字段有点麻烦,有没有其他方式替代?”

没想到产品说:“其实我们也只是为了数据分析,这个字段写日志里就行了,隔壁项目组每天拉日志自己分析。”

我:???

完美解决!

这让我深刻体会到:代码难实现,不如从需求入手解决问题。我们很多时候过度工程了,结果产品压根没打算用数据库。

06

Plan B:扩展表,按需关联查询

虽然日志方案优雅解决了这次需求,但我还是想总结一些如果一定要入库,有哪些可行的低成本方案。

最常见的是 “扩展表”方案:

虽然查询麻烦点,但优点是:

• 主表结构稳定;

• 扩展字段可动态管理;

• 不影响现有业务逻辑。

07

高级玩法:JSON 扩展字段

后来合作方又提了一个很有意思的方案:

不如你们统一定义一个 ext 字段,类型为 TEXT 或 JSON ,所有新增字段都塞到里面去,用规则解析即可。

比如:

{ "source":"marketing", "utm_campaign":"202406-promo", "coupon":"ABCD1234"}

这样一来,以后有新字段就塞进去,不用再修改表结构,非常灵活。

这种设计也叫做 “schema-less”扩展结构,在很多互联网公司是标准做法。

08

最终解决方案:利用冗余字段,回收再利用

我们在查表结构的时候发现,订单表里有一个历史字段叫 remark_ext ,一直没人用,占了512长度。

我灵光一闪:干脆把我们的扩展信息塞到这个冗余字段里!

于是我们约定了格式,做了封装写入,完美解决问题,而且:

• 不用加字段;

• 不用关联查询;

• 不用上线新表。

当然产品也提了个关键问题:“这个字段长度够吗?后面扩展多了怎么办?”

我查了下现在是512,考虑到未来需求,打算调到2000。

然后我在测试环境搞了个1亿条记录的表,执行:

ALTER TABLEorder MODIFY COLUMN remark_ext VARCHAR(2000);

结果发现:

• 调大字段长度不会锁表;

• 调小字段长度会锁表(因为要判断是否超长)。

真的是写一次,学到一堆细节。

09

总结一下

加个字段,真没你想得那么简单,尤其在核心大表上。整件事从头到尾,我学到了很多:

• 技术方案不是唯一解,需求变更有时比技术更省事;

• 尽量避免改动核心表结构,可以用扩展表、JSON 字段或冗余字段;

• 别小看线上 DDL 的风险,谨慎评估业务影响;

• 最后一点:测试环境永远是你最好的朋友,大胆模拟1E 数据才能安心上线。

面试官:你怎么在千万级订单表加字段?

我:我先不加,看还能不能不加。

如果你也有类似经历,欢迎评论区交流

来源:墨码行者

相关推荐