如何选型业务扩展模式以应对未来需求增长？

业务发展过程中，增加字段是很常见、频繁的，因此怎么存储新增的字段是要重点考虑的因素。下面结合笔者的经验，总结一下各种业务扩展模式选型的优缺点、适用场景，如何让系统保持良好的业务扩展性。 方案选项 1. 最朴素方案：MySQL表直接加字段 实现： 在表中新增字段（ALTER TABLE ... ADD COLUMN ...）。 优点： 简单直接，快速迭代 缺点： 需要频繁修改表结构 字段膨胀导致表臃肿，索引效率下降（mysql单行记录有大小上限，65535字节；特别地，TEXT、BLOB另外分开存储，占9到12字节） 适用场景： 业务初期频繁加字段 或该字段为通用字段，适用于所有记录 2. 按业务领域聚合字段（增量更新） 实现： 将新增字段按业务域划分，比如业务一的信息都放到field_1，业务二的信息都放到field_2，每个字段是json格式、方便后续扩展。 优点： 业务聚合：相同业务领域信息存在一个字段内，无需每次DDL新增字段 缺点： 每次更新都要先查DB的值，merge本次变更后再写入DB 需做好并发控制，否则可能丢失变更内容（可通过乐观锁、或悲观锁控制，取决于并发程度） 仍然存在mysql单行大小限制 适用场景： 小型项目，不做推荐 3. 按业务领域垂直拆表 实现： 相近业务领域的字段，做垂直分表（如拆为订单信息表order_info、订单支付表order_payment、订单物流表order_logistics）。 优点： 彻底解耦业务域，各表独立演进 按需查表，提升查询性能 缺点： 每个垂直分表仍是在表内新增字段 业务扩展的难易程度，取决于垂直拆分得是否合理 适用场景： 业务模式已经稳定 或业务边界清晰的项目 4. 主表 + 动态扩展表（通过业务ID关联） 实现： 主表：存储核心字段（如业务ID、其它通用关键字段） 动态扩展表：存储动态扩展字段，与主表通过业务id关联。包括扩展key、扩展value（可以是json格式，方便后续扩展） 每次新增字段：(1）新增一个扩展key，在扩展value里存储内容；(2）或在已有扩展key的value中新增字段。 之所以通过动态扩展表来实现，是因为很多字段并非通用的，而仅针对部分记录。