架构升级需围绕数据一致性、扩展性、运维成本重新设计系统边界，依次经历主从复制、分库分表、分布式演进三阶段，并根据业务实际采用混合架构。

单机数据库撑不住业务增长时，架构升级不是简单换工具，而是围绕数据一致性、扩展性、运维成本重新设计系统边界。

从单机到主从：读写分离是第一道分水岭

当查询压力远大于写入，主从复制能快速缓解瓶颈。主库专注事务处理，从库承担报表、搜索、APP列表等读请求。关键在延迟可控和读写路由透明：应用层需识别事务上下文（如带写操作的请求强制走主库），中间件（如ShardingSphere、ProxySQL）或客户端驱动可自动完成路由。注意从库延迟突增时的降级策略——比如超500ms自动切回主库读，避免脏数据被前端缓存。

分库分表：水平拆分必须回答三个问题

单表超2000万行或单库QPS持续过5000，就得考虑拆分。但先明确：
• 按什么字段拆？优先选高频查询+高基数的业务主键（如user_id、order_id），避免跨库JOIN；
• 拆成多少片？不盲目追求数量，16~64个分片较易运维，太多会放大分布式事务与聚合查询成本；
• 扩容怎么平滑？用一致性哈希或虚拟节点预分配，避免数据迁移停服。例如订单库按order_id取模，新扩节点时仅迁移部分哈希段，配合双写+校验完成灰度切换。

走向分布式：放弃强一致，换取可用性与弹性

跨城多活、海量写入、实时分析等场景下，传统关系型数据库难以兼顾。此时转向NewSQL（如TiDB、CockroachDB）或分层架构：
• 核心交易走分布式事务引擎，保障关键链路ACID；
• 日志类、行为类数据进宽表或OLAP引擎（如Doris、StarRocks），用最终一致性换性能；
• 全局ID、分布式锁、幂等控制等能力下沉为基础设施，避免每个服务重复造轮子。重点不是“能不能分布式”，而是“哪些环节必须强一致，哪些可以妥协”。

别忘了退路：混合架构比非此即彼更现实

多数业务不需要全量上分布式。常见有效模式是：
• 用户中心、订单中心等核心域做分库分表；
• 商品、内容等读多写少模块保留在高性能单机库（如MySQL 8.0+并行查询+只读实例）；
• 新业务直接对接云原生数据库（如PolarDB、Aurora），享受存储计算分离与秒级弹性。架构演进本质是匹配业务阶段——不是越分布越好，而是让每一分复杂度都解决真实痛点。