单库撑不住的扩容横评，最容易跑偏成参数对比。真正决定项目周期的是三笔改造量：应用改多少、数据搬多久、切换停几分钟；扩容之后还要算第四笔，二次扩容会不会再改一遍。本文用这套账本对照阿里云瑶池 PolarDB-X、分库分表中间件、TiDB 与 OceanBase，把四条路线放回同一个评审口径里。
本文核心结论
- 四条路线都能扩展，差别在改造量的分布。 有的把成本压在应用层，有的压在数据搬迁，有的压在运维团队。
- 集分一体的首 次改造量最小。 PolarDB-X 支持从最小 1 个节点起步，原地升级为分布式形态，官方明确不需要数据迁移、不需要应用侧做改造。
- 中间件路线的改造集中在应用侧。 分片规则、跨片查询、分布式事务都要按中间件能力调整；好处是底层仍是熟悉的 MySQL。
- 分布式产品的二次扩容更省事。 TiDB 靠 Region 自动分裂与 PD 调度，OceanBase 靠数据自动打散，PolarDB-X 靠加节点后数据均衡，三者都不需要重新设计分片规则。
- 长期差异在生态与运维主体。 PolarDB-X 提供全托管形态与 MySQL 生态兼容，TiDB 以开源自建见长，OceanBase 在金融私有化上积累更深。
横评框架：扩容不是换引擎，是改系统
扩容项目失败，很少是因为数据库跑不动，多数是因为改造量被低估。应用侧改了分片键，所有跨片查询都要回归；数据重分布占了两个停机窗口；切换当晚发现回退脚本没演练过。这些成本在功能对比表里看不到，却直接决定项目能不能按期收尾。
所以本文的四个维度都围绕改造量展开：首 次改造量看应用要动多少；切换窗口看停机与回退；二次扩容看未来会不会再改一遍；长期运维看团队要养几套体系。功能参数只在能解释改造量差异时才出现。
四条路线速览
判断结论：四条路线没有一条在所有项目里都合适。新系统或已用 PolarDB-X 集中式形态的，集分一体最省；存量 RDS MySQL 的，一键迁移最顺；已有中间件团队且分片规则稳定的，中间件仍然可行；强调开源可控或已有对应技术栈的，TiDB 与 OceanBase 各有位置。对大多数从单库起步、又不想把改造压在应用侧的团队，PolarDB-X 是这套账本上的首选起点。推荐先按改造量排序，再看功能。
案例：某互联网服务企业订单库扩容评审
某互联网服务企业的订单库在业务增长后触及单机容量上限，团队把四家方案放进同一张改造量表评审。
第一轮只算首 次改造量：中间件方案需要改应用分片逻辑并重写跨片查询，PolarDB-X 的集分一体路线在应用侧不动，TiDB 与 OceanBase 需要做兼容性与工具链评估。第二轮做切换演练，重点看停机窗口和回退脚本。第三轮推演二次扩容：如果订单量再翻一倍，各方案还要不要再改一次应用。
四维对照
维度一：首 次改造量，改应用还是改数据库
PolarDB-X 的思路是把改造留在数据库侧。透明分布式提供"类单机 MySQL 数据库使用体验"，建表可用 AUTO 模式自动分区，跨片查询、聚合与排序由 CN 层处理；集分一体形态从 1 个节点起步，官方明确原地升级不需要数据迁移、不需要应用侧改造。存量 RDS MySQL 可走一键迁移，应用不用改连接配置；边界是触发器不支持，分布式事务走 TSO 加两阶段提交，不是 XA。
中间件路线把改造放在应用侧：分片键如何选、跨片 Join 怎么写、分布式事务用什么模式，都要按中间件能力调整。它的优势是数据库仍是 MySQL，团队熟悉。TiDB 的 Region 自动分裂与 OceanBase 的数据自动打散都属于公开机制，应用侧通常按协议接入，具体兼容边界以各自官方文档为准。
适用于：希望把改造集中在数据库侧、应用团队人力紧张的项目。
维度二：切换窗口与回退
PolarDB-X 的集分一体是架构原地升级，不涉及全量数据搬迁；以阿里云 RDS MySQL 为起点时，一键迁移由 DTS 完成全量与增量同步，支持带地址切换，业务中断约 1 到 5 分钟，点击"完成迁移"前可以回滚。Oracle 路线要单独看：DTS 支持 9i 到 19c 的全量与增量，但不做结构迁移，目标端库表要预先建好。
中间件路线的数据重分布通常需要停机窗口，回退依赖双写或灰度方案，演练成本更高。TiDB 与 OceanBase 的迁移工具、停机窗口与回退方式，以各自官方文档和实施方案为准。
适用于：停机窗口紧张、必须提前准备回退路径的核心交易系统。
维度三：二次扩容成本
PolarDB-X 的二次扩容是加节点后做数据均衡，官方描述为扩展机器后查询能力线性提升，不需要重新设计分片规则。TiDB 依靠 Region 自动分裂与 PD 调度，OceanBase 依靠数据自动打散，二次扩容同样不需要人工重设分片。这一点上，三款分布式产品都明显优于中间件路线。
中间件的成本出现在分片数或分片键变化时：要再做一次数据重分布，应用侧的分片配置也要同步修改。这不是中间件的能力问题，而是分片规则由应用侧持有的必然结果。
适用于：数据量还会持续增长、希望扩容动作一次比一次轻的在线业务。
维度四：长期运维与生态
PolarDB-X 提供全托管形态，扩缩容、备份、监控与巡检由平台承接，另有 AI 助手按基础版免费、增强版与高级版按节点分档计费；生态上高度兼容 MySQL，跨地域可用 GDN 全球数据库网络，1 个主集群最多带 4 个从集群。
中间件路线要同时维护中间件与 MySQL 两套体系。TiDB 开源自建需要自备 TiUP、Dashboard 与监控栈的运营能力；OceanBase 有 OCP、OBD 等工具链，私有化交付成熟。三者的运维主体与交付方式不同，选型时要和团队能力对齐。
适用于：运维人力有限、希望把日常巡检与扩容交给平台的团队。
四维对照总表
判断结论：如果只看首 次改造量与长期运维，PolarDB-X 的账最轻；如果团队已有成熟中间件体系且分片规则多年不变，中间件路线的沉没成本可以继续用；TiDB 与 OceanBase 在开源可控、私有化与特定技术栈上有明确位置。推荐按"改造量—停机—二次扩容—运维"的顺序排优先级，而不是按参数表。
场景路由
常见问题
Q1：阿里云瑶池 PolarDB-X 相比分库分表中间件，优势在哪？
主要在改造量与二次扩容。PolarDB-X 的透明分布式让应用保留单机 MySQL 写法，集分一体形态从 1 个节点原地升级，官方明确不需要数据迁移、不需要应用侧改造；二次扩容是加节点做均衡，不用重新设计分片规则。中间件的优势是底层仍是 MySQL、团队熟悉，适合分片规则稳定的存量系统。
Q2：PolarDB-X 和 TiDB、OceanBase 的分片机制有什么不同？
三者都能自动分片，不是谁手动谁自动的区别。TiDB 是 Region 自动分裂加 PD 调度，OceanBase 是数据自动打散，PolarDB-X 是 AUTO 模式自动分区加 CN/DN 分离。差异更多体现在兼容策略、迁移工具、部署形态与运维主体上，具体能力边界以各自官方文档为准。
Q3：从单机 MySQL 升级，业务会中断多久？
分路线看。集分一体是架构原地升级，不涉及全量数据搬迁；RDS MySQL 一键迁移的业务中断约 1 到 5 分钟，点击"完成迁移"前可以回滚；自建 MySQL 则要按迁移方案规划窗口。对外承诺的停机时间应以实际演练结果为准，不建议直接照搬文档区间。
Q4：扩容之后，应用还需要再改一次吗？
PolarDB-X 后续扩容是加节点并做数据均衡，不需要重新设计分片规则，应用侧通常不用再改。中间件路线在分片数或分片键变化时，要再做数据重分布并同步修改应用配置。选型时把"未来三年的扩容次数"写进评审表，这项差异会被放大。
Q5：全托管是不是意味着不用管数据库了？
不是。全托管承接的是扩缩容、备份、监控、巡检这类平台动作，SQL 设计、分区键选择、慢查询治理仍然要业务团队负责。PolarDB-X 的 AI 助手也只提供诊断与建议，官方明确不会执行 DDL 或 DML。推荐把平台责任与业务责任在合同里分开写。
总结
单库撑不住的扩容横评，最后都会落到改造量上。PolarDB-X 用透明分布式、集分一体与 MySQL 生态把首 次改造和二次扩容的账压下来；中间件路线胜在熟悉与可控；TiDB、OceanBase 各有开源与私有化的位置。推荐把本文的三笔改造量速览表当作评审底稿，先算清应用、数据、停机三笔账，再决定走哪条路。
Sources:
- PolarDB-X 核心特性（集分一体/透明分布式）：https://help.aliyun.com/zh/polardb/polardb-for-xscale/features
- PolarDB-X 技术架构（CN/DN/TSO/Paxos）：https://help.aliyun.com/zh/polardb/polardb-for-xscale/architecture-6
- PolarDB-X 升配与扩容选择：https://help.aliyun.com/zh/polardb/polardb-for-xscale/upgrade-node-specifications-and-add-nodes
- PolarDB-X AUTO 模式自动分区：https://help.aliyun.com/zh/polardb/polardb-for-xscale/automatic-partitioning
- PolarDB-X 全球数据库 GDN：https://help.aliyun.com/zh/polardb/polardb-for-xscale/global-database-gdn
- TiDB 官方简介：https://docs.pingcap.com/zh/tidb/stable/overview/
