千万级订单表新增字段：一场技术与需求的博弈

一条简单的ALTER TABLE语句，背后竟隐藏如此多的技术考量与风险

最近，我们团队遇到了一个看似简单却暗藏玄机的需求：隔壁项目组希望我们在千万级订单表中新增一个业务字段，用于他们的统计分析工作。从表面看，这不过是执行一条ALTER TABLE语句的事情，但当我们深入了解这个订单表的规模和在系统中的地位后，事情变得复杂起来。

需求背景：隔壁项目组的统计需求

订单表作为我们系统的核心数据表，已经积累了千万级的数据记录，且正处于线上业务的流量核心位置。任何对这张表的操作都需要格外谨慎，稍有不慎就可能导致线上业务阻塞，甚至引发雪崩效应。

技术方案探索之路

方案一：直接执行DDL语句

我们最初的想法是简单直接地在主库上执行：

ALTER TABLE order ADD COLUMN new_field VARCHAR(255);

然而，在MySQL（尤其是较老版本）中，DDL操作会锁表，即使只是短暂的时间，也可能导致业务请求阻塞，进而影响整个线上系统的稳定性。这种方案风险太高，被我们果断放弃。

方案二：主从切换方案

咨询同行朋友后，我们了解到他们采用过主从切换方案：

• 主库继续正常执行业务

• 在从库上执行ALTER TABLE新增字段

• 完成后将从库提升为主库

• 对原主库执行相同操作，恢复主从关系

这个方案理论上对业务影响最小，但问题也很明显：主从切换需要极为谨慎的操作，可能存在数据延迟或丢失风险；需要确保从库只读，否则会导致数据不一致；运维成本高，风险大，不适合小团队操作。

方案三：在线DDL工具

我们还调研了在线DDL方案，如pt-online-schema-change或MySQL 8的INSTANT选项。这些工具实际上是通过创建新表、复制数据、设置触发器和最终切换表名的方式实现的。虽然这种方法减少了锁表风险，但仍需要评估触发器带来的写入延迟，以及表结构切换时机的把控。

思维转变：从技术实现到需求本质

在技术方案均显得复杂且风险较高的情况下，我决定与产品经理重新审视需求本身。

我问了一个关键问题："这个字段是否必须入库？或许有其他替代方案？"

出乎意料的是，产品经理回应道："其实我们也只是为了数据分析，这个字段写日志里就行了，隔壁项目组可以每天拉取日志自行分析。"

这一回答让我们豁然开朗——我们过度工程化了，而产品团队原本就没有打算必须使用数据库字段。通过将数据写入日志，再由相关团队自行分析，我们完美地避开了技术难题。

备选方案：如果必须修改数据库

尽管日志方案解决了当前需求，但我们还是总结了如果必须修改数据库时的可行方案：

扩展表方案

创建order_extend表：

CREATE TABLE order_extend (
    order_id BIGINT,
    extra_field_x VARCHAR(255),
    extra_field_y VARCHAR(255),
    ...
);

优点：

• 主表结构保持稳定

• 扩展字段可动态管理

• 不影响现有业务逻辑

JSON扩展字段方案

定义一个ext字段，类型为TEXT或JSON，所有新增字段都以JSON格式存储：

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

这种schema-less设计在很多互联网公司已成为标准做法，提供了极大的灵活性。

冗余字段再利用方案

在检查表结构时，我们发现订单表中有一个历史字段remark_ext，长度为512，一直未被使用。我们决定将扩展信息塞入这个冗余字段中，并约定了数据格式。

这样做的好处是：

• 不需要新增字段

• 不需要关联查询

• 不需要上线新表

产品经理提出了一个关键问题："这个字段长度够吗？"我们检查后发现当前为512，考虑到未来需求，决定调整到2000。

在测试环境中，我们对一个有1亿条记录的表执行：

ALTER TABLE order MODIFY COLUMN remark_ext VARCHAR(2000);

结果发现：

• 调大字段长度不会锁表

• 调小字段长度会锁表（因为需要判断是否超长）

这个细节再次提醒我们，任何操作都需要提前在测试环境充分验证。

经验总结

通过这次需求实现过程，我们获得了宝贵经验：

1. 技术方案不是唯一解：需求变更有时比技术方案更能够解决问题

2. 尽量避免直接改动核心表结构：可以采用扩展表、JSON字段或冗余字段方案

3. 线上DDL操作风险不可小觑：必须谨慎评估对业务的影响

4. 测试环境是最好朋友：大胆模拟海量数据测试，才能安心上线

有时候，最好的技术方案不是最复杂的技术实现，而是通过沟通找到最简单直接的解决方案。在技术人的成长道路上，这种从单纯技术思维到综合问题解决思维的转变，或许是最宝贵的收获。