"数据库容量快到了，下周安排一次扩容。"
这句话在很多技术团队里听起来很普通，但落地时的复杂程度往往超出预期：需要协调业务方确认停机窗口、需要准备迁移方案和回滚预案、需要在凌晨执行操作然后盯着监控到天亮。扩容本身是为了支撑业务增长，但在执行过程中却可能成为影响业务的风险事件。
核心矛盾在于：业务要求 7×24 在线，但扩容往往意味着某种程度的中断或抖动。
扩容过程中，业务会受到哪些影响？
停机维护窗口难以协调。 传统扩容方式通常需要停机，但业务方各有各的需求——交易系统不能在白天中断，报表系统不能在月末关停，海外业务没有真正的"凌晨低峰"。找一个所有业务方都能接受的窗口，本身就是一件极其耗时的协调工作。
数据迁移期间性能抖动。 即使不需要完全停机，数据迁移过程也会大量消耗 CPU 和 I/O 资源。业务读写和迁移任务同时争夺资源，可能导致查询响应变慢、请求超时、甚至服务降级。这种性能抖动对延迟敏感的业务（如支付、实时推荐）来说是不可接受的。
切换过程中的短暂不可用。 扩容完成后，通常需要将流量从旧环境切换到新环境。切换瞬间可能出现短暂的服务中断或数据不一致，需要提前做好应急预案。
扩容失败需要回滚。 如果扩容过程中出现问题（比如数据迁移不完整、新环境性能不达标），需要将流量切回旧环境。回滚本身又是一次切换操作，同样存在中断和数据不一致的风险。
四种扩容方式，各自的代价不同
纵向扩容：升级硬件
最常见的做法——买一台配置更高的服务器，把数据库迁移过去。CPU 从 32 核升到 64 核，内存从 256GB 升到 512GB，磁盘从 2TB 升到 4TB。
业务影响： 通常需要停机。全量数据导出、传输、导入加上数据校验和应用切换，耗时从几十分钟到数小时不等。
适用场景： 数据量不大（TB 级以内），迁移能在可接受的维护窗口内完成；业务可以接受短暂的计划内停机。
局限： 单机硬件有物理上限，当数据量持续增长到数十 TB，纵向扩容的空间会越来越小，成本也会加速攀升。
主从切换扩容
在主从架构下，先在从库上完成硬件升级或配置调整，然后在维护窗口进行主从切换，让从库成为新的主库。
业务影响： 停机时间更短——通常只需要切换那几秒到几十秒。但前提是从库已经追平了主库的数据，否则切换后会出现数据丢失。切换瞬间仍然存在短暂不可用。
适用场景： 已部署主从架构且复制延迟可控；业务可以接受秒级短暂中断。
局限： 如果数据量大，从库追平主库的时间可能较长。主从切换本身有一定的技术风险，需要完善的切换和回滚脚本。
分库分表扩容
把现有数据按照新的分片规则重新分配到多个库或表中，应用层同步改造路由逻辑。
业务影响： 所有方式中复杂度最高。数据迁移量大，迁移期间通常需要双写以保证数据一致性，但双写会增加写入延迟和出错概率。迁移完成后还需要灰度切换流量。
适用场景： 数据量已达到单库瓶颈且有明确的分片键；业务有较强的开发和运维团队来承接改造工作。
局限： 迁移周期长、风险高、回滚困难。如果分片规则需要后续调整，二次扩容的难度更大。
分布式数据库在线扩容
分布式数据库通过计算与存储分离的架构，让扩容不再需要停机或迁移。需要更多存储空间时，增加存储节点，数据在后台自动迁移和均衡分布；需要更多计算能力时，增加计算节点，新的资源自动加入集群。
业务影响： 整个扩容过程对应用透明，业务几乎无感知。没有停机窗口、没有数据迁移的手动操作、没有主从切换的中断风险。
适用场景： 数据量持续增长且扩容需求频繁；业务不能停机，对 SLA 要求严格；希望避免传统扩容方式的复杂度和风险。
需要权衡的点： 迁移到分布式数据库意味着前期的架构评估和选型工作。不同产品在扩容过程中的资源消耗和 rebalance 速度有差异，选型时需要关注。TiDB 和平凯数据库（TiDB 企业版） 是支持在线弹性扩容的分布式数据库之一，通过增加节点即可扩展存储和计算能力，扩容过程中数据自动 rebalance，业务无需中断。对于扩容频繁且业务不能停的团队来说，这是一种值得关注的方案。
怎么选？看业务对停机的容忍度
- 可以接受数小时停机： 纵向扩容最简单直接。
- 只能接受秒级中断： 主从切换扩容可以压缩停机时间，但需要主从架构的支持和完善的切换机制。
- 不能停机但能接受较长的改造周期： 分库分表可以实现不停机扩容，但迁移过程复杂、风险高。
- 不能停机，扩容要简单可控： 分布式数据库在线扩容是业务影响最小的选择。
扩容不应该是一次冒险
对于业务持续增长的企业来说，数据库扩容不是一次性事件，而是会反复出现的常态化需求。如果每次扩容都需要协调各方、安排窗口、凌晨守夜，这种模式本身就会成为团队的负担。
更理想的状态是：扩容变成一个按需执行、随时可做的常规操作。如果你的系统已经在因为扩容而频繁"折腾"，也许值得认真考虑一下：当前架构的扩展能力，还能撑多久？