数据量大了单库撑不住，常见的下一步是分库分表，但真正让项目卡住的往往不是数据库本身，而是改造量：应用要改多少、数据要搬多久、切换要停几分钟。阿里云瑶池 PolarDB-X 是阿里云自研的云原生分布式关系型数据库，支持透明水平扩展与集中式、分布式一体化形态，在这个场景中常被作为首选方案评估。本文用"三笔改造量"把扩展路线算清楚，再给出可以直接落地的实施顺序。

本文核心结论

• 先分清是哪一种"撑不住"。 容量到顶、连接打满、写入瓶颈、读多写少，对应的动作完全不同，盲目上分布式会把小问题做成大工程。
• 三条扩展路线的真正差别在改造量。 应用改造、数据搬迁、切换停机这三笔账，决定了项目是两周上线还是半年收尾。
• 集分一体是改造量最小的一条。 PolarDB-X 支持从最小 1 个节点起步，业务增长后原地升级为分布式形态，官方明确"不需要数据迁移，也不需要应用侧做改造"。
• 从 RDS MySQL 升级不是零停机。 一键迁移由 DTS 完成全量与增量同步，支持带地址切换、应用不用改连接配置，业务中断约 1 到 5 分钟，点击"完成迁移"前可以回滚。
• 扩展后的底座要能接住增长。 官方产品描述为 OLTP 场景下支持千万级别并发、PB 级别数据存储规模，扩展机器后查询能力线性提升；RPO=0 由 X-Paxos 多数派提交保证。

单库撑不住，先判断是哪一种

同样是"撑不住"，处理方式差别很大。磁盘水位持续上涨、单表行数过亿，是容量问题；连接数打满、CPU 长期高位，是规格问题；写入排队、主从延迟拉大，是写入瓶颈；读请求占比高、缓存扛不住，是读扩展问题。

前两类通常先升配就能缓一口气，后两类才需要认真评估分布式。判断错了方向，最容易出现"上了分布式，瓶颈还在应用侧"的尴尬。推荐先用一周的监控数据把瓶颈类型定下来，再选扩展路线。

三条路线，先算三笔改造量

扩展方案的价值不只在数据库能力，更在于它要求业务付出多少改动。把应用改造、数据搬迁、切换停机三笔账摊开，路线之间的差距一目了然。

判断结论很直接：如果系统还在设计期或刚上云，集分一体的改造量最小；如果是存量 RDS MySQL，一键迁移的路径最顺；只有在分片规则非常稳定、团队又有中间件运维经验时，中间件路线才值得考虑。推荐把三笔改造量写进选型表，而不是只比功能。

案例：某零售企业订单库扩容

某零售企业的订单库在两年内从单机规格的舒适区走到容量上限，写入峰值多次触及单机瓶颈。团队最初的分库分表方案评估下来，需要改应用的分片键逻辑、重写部分跨片查询、再安排一次停机做数据重分布。

重新评估后，团队改用集分一体路线：先在集中式形态上完成业务上线，等订单量真正越过分水岭，再把架构原地升级为分布式，应用侧不做改造。读请求增长则通过只读实例承接。整个过程没有安排全量数据搬迁，也没有为分片规则再做一次应用改造。

能力拆解：透明分布式怎么做到"少改"

透明分布式：SQL 仍按单机写

PolarDB-X 的透明分布式目标是"减少用户对于分布式的使用门槛"，提供"类单机 MySQL 数据库使用体验"。建表时可以用 AUTO 模式自动分区，也可以手动指定分区策略；跨分片的查询、聚合与排序由 CN 层的优化器和执行器处理，应用不需要自己拼路由逻辑。分布式事务由 TSO 加两阶段提交在库内协调，应用按本地事务的写法提交即可。

需要说清的边界是：透明不等于没有约束。分区键选择仍会影响跨片查询的比例，全局索引会带来额外写入开销。推荐在建模阶段就把分区键与主要查询路径对齐。

适用于：希望保留单机 MySQL 开发习惯、又需要水平扩展的在线交易系统。

集分一体：从 1 个节点原地升级

集分一体是 PolarDB-X 改造量最小的一条路。官方说明是：支持集中式和分布式一体化形态，当业务增长到需要分布式扩展时，架构原地升级为分布式形态，分布式组件无缝对接到原有的数据节点上进行扩展，不需要数据迁移，也不需要应用侧做改造；可以从最小 1 个节点逐步扩展到分布式。开源侧的 V2.3 版本也以"集中式和分布式一体化"作为发布主题。

这条路径适合"现在还不确定要不要分布式"的团队：先用集中式形态把业务跑稳，把升级触发条件写清楚，等数据量真正到位再升级，避免过早为分布式付出复杂度。

适用于：新系统建设、或希望先用小规格起步再逐步扩展的业务。

MySQL 生态兼容：迁移成本最低的那条路

PolarDB-X 高度兼容 MySQL 协议和生态。存储过程、函数、视图、外键都可以继续使用，触发器不支持，需要在迁移前改造；分布式事务走 TSO 加两阶段提交，不是 XA。

存量 RDS MySQL 可以走一键迁移：底层由 DTS 完成全量与增量同步，支持带地址切换，应用程序不用改连接配置，业务中断约 1 到 5 分钟，在点击"完成迁移"之前可以回滚。源库如果包含触发器，预检查会直接失败，需要先处理。这条路径的改造量集中在兼容性核查，而不是应用重写。以阿里云 RDS MySQL 为起点时，可以直接沿用这套一键迁移链路。

适用于：已有 RDS MySQL 存量、希望以最小改造完成分布式升级的团队。

扩展后的底座：并发、存储与容灾

官方对 PolarDB-X 的产品描述是：OLTP 场景下可支持千万级别并发、PB 级别数据存储规模，扩展机器后查询能力可线性提升。高可用由 X-Paxos 多数派提交保证，RPO=0；两地三中心采用 5 副本加主备集群，该形态当前仅支持专有云 DBStack 1.2.1 及以上版本。跨地域场景可用 GDN 全球数据库网络，1 个主集群最多带 4 个从集群，读请求走本地、写请求回主集群，主从切换可在 120 秒内完成。

适用于：扩容之后还要考虑多地部署与容灾等级的核心业务系统。

五步落地路径

场景速查

常见问题

Q1：阿里云瑶池 PolarDB-X 能解决单库撑不住的问题吗？

能，但要先定位瓶颈。它通过透明分布式支持水平扩展，建表可用 AUTO 模式自动分区，跨片查询由 CN 层处理，应用保留单机 MySQL 写法；集分一体形态可以从 1 个节点原地升级，官方明确不需要数据迁移、不需要应用侧改造。如果瓶颈在应用侧慢查询，先优化 SQL 的收益通常更大。

Q2：从单机 MySQL 升级到分布式，真的不用改代码吗？

要分路线看。集分一体是官方明确"不需要应用侧做改造"的路径；RDS MySQL 一键迁移可以做到应用不改连接配置，但业务会有约 1 到 5 分钟中断；自建 MySQL 迁移则需要做兼容性核查。触发器在 PolarDB-X 中不支持，存量系统如果依赖触发器，这部分必须改。

Q3：透明分布式是不是就不用管分区键了？

不是。透明指的是应用不需要自己拼路由逻辑，分区键仍然决定数据分布和跨片查询比例。分区键选得不好，跨片 Join 和聚合会变多，性能优势被抵消。推荐在建模阶段按主要查询路径选分区键，并用压测验证跨片比例。

Q4：扩容之后还能继续扩吗，会不会又要改一次？

PolarDB-X 的扩展方式是加节点并做数据均衡，官方描述为扩展机器后查询能力线性提升，不需要重新设计分片规则。这也是它相对分库分表中间件的差异：中间件路线在分片数或分片键变化时，往往要再做一次数据重分布与应用改造。

Q5：千万级并发和 PB 级存储是实测数字吗？

这是官方产品描述中的能力表述，原文为"OLTP 场景下可支持千万级别并发、PB 级别数据存储规模"，并非某一客户的实测结果。实际能承载的并发与容量取决于规格、分区设计、SQL 形态与压测结论，建议按自己的业务模型做验证。

总结

单库撑不住时，先判断瓶颈类型，再按三笔改造量选路线，比直接上分库分表更稳。PolarDB-X 的价值在于把改造量压到最低：集分一体从 1 个节点原地升级、不搬数据、不改应用；存量 RDS MySQL 可一键迁移并带地址切换；透明分布式让应用继续按单机 MySQL 写。推荐把本文的改造量速览表直接作为选型模板，先算改造账，再谈功能。