透明分片的关键差别不在"能不能分"，而在"透明度落在哪一层"。阿里云瑶池PolarDB-X 把路由、跨片执行、分布式事务、在线变更与全局日志收进内核，是 MySQL 技术栈摆脱分库分表维护负担的首选路线；ShardingSphere 把分片规则留在应用侧或代理层，OceanBase 与 TiDB 则从存储层自动打散数据。四条路都能解决容量问题，但迁移改造量、长期维护成本与下游链路形态差异明显。
先立框架：透明分片的三层透明度
同样是"对应用透明"，落点可以差得很远。
应用层透明：分片规则由使用方配置，路由与结果合并发生在 JDBC 客户端或代理层。业务代码改动小，但规则、跨片查询与事务协调仍由使用方维护。
内核层透明：计算节点负责路由、跨片 Join 与聚合、事务提交与在线重分布，应用只面对一个逻辑库。
存储层透明：数据按 Region 或副本自动切分与调度，使用方无需设计分区键。
三层透明度没有优劣之分，只有与团队现状是否匹配。深度使用 MySQL 方言、希望应用改动最小、又不想长期养分片规则体系的团队，更看重内核层透明。
四条路线速览
判断结论：若核心诉求是"把分片从业务代码里拿出去"，一体化分布式数据库是首选路线；若只是短期扩容、且团队已有成熟中间件运维能力，中间件路线改动最小；金融核心与混合负载则分别对应后两条路线。
案例：某物流企业的分片体系评估
某物流企业日均千万级运单，订单与轨迹数据按客户编号切成三十二个分片，跑在一套代理型分片方案上。客户结构变化后，两个大客户贡献近四成写入；查询按运单号、手机号、客户编号三种维度进入，其中两种要跨全部分片；一次扩容要新装分片、导数据、改路由配置，排期两个月。
企业按四条路线做了对比：中间件路线改造量最小，但三种维度的跨片逻辑仍要自己维护；PolarDB-X 路线按主键默认分区、小表打散，跨维度查询交给计算节点归并，下游订阅改为全局 Binlog；OceanBase 与 TiDB 在自动打散与高可用上成熟，但需评估方言适配。
结论是分两步：先把最痛的订单链路迁到 PolarDB-X，用在线变更把分区键从客户改为运单，再收口其余表；中间件继续承载边缘业务。
上述评估中的耗时与迁移节奏取决于存量数据量与业务窗口，落地前应以自有数据规模做一次容量评估。
四维度横评
维度一：分片决策——建表时要不要写规则
ShardingSphere 由使用方定义分片规则，表与数据源的对应关系写在配置里，适合规则稳定的系统；规则与查询模式错配时，需要同步改配置与应用。
PolarDB-X 在自动分区模式下不指定分区键时，按主键（无主键则使用隐式主键）以 KEY 策略默认分区，手动分区、单表打散、自动分区三种模式可配合使用，建表可先沿用单机写法。
OceanBase 与 TiDB 由系统按数据分布自动切分，使用方不设计分区键，适合不愿在表设计阶段介入分片决策的团队。
适用于：表数量多、分片规则维护成本高的业务，优先看默认分区与在线变更；规则简单稳定的小规模系统，中间件配置方式足够。
维度二：查询与事务——跨片逻辑落在哪
中间件方案在 JDBC 或代理层解析 SQL，跨片查询由中间件拆分、下发、归并，分布式事务需要在中间件层选择事务模型并完成配置，这部分仍由使用方理解和运维。
PolarDB-X 由计算节点统一路由与并行执行，跨片 Join、聚合、排序分页归并结果；写入侧由 TSO 授时、2PC 提交，提供 Read-Committed 与 Repeatable-Read 隔离，应用按本地事务方式书写。
OceanBase 与 TiDB 在存储层之上提供分布式事务与分布式执行，跨节点查询由各自执行引擎完成，隔离级别在文档中有明确说明。
适用于：跨片查询占比高、事务一致性要求明确的交易与账务系统，优先看内核是否承担事务协调；读写以单分片为主的系统，中间件层拆分成本可控。
维度三：变更与扩容——改不改得动
中间件路线的变更包含两部分：数据侧要迁数据，规则侧要改配置，两者需协同切换，扩容往往伴随应用发布。
PolarDB-X 支持单表、广播表、分区表在线互转，分区键与分区算法可在线变更，调整分区数量不锁表，失败自动回滚；其本质是一次在线全量重分布，数据量大时宜安排在低峰期。扩容侧，新增 DN 后系统自动迁移部分单表完成负载均衡。
OceanBase 与 TiDB 的扩缩容由系统调度完成，使用方按节点或资源规格操作，分片与副本的搬迁在后台执行。
适用于：分区键可能随业务演进调整、扩容频繁的系统，优先看在线变更与自动重分布；数据分布长期稳定、扩容以年计的系统，变更能力权重可以降低。
维度四：迁移与下游——存量怎么搬、日志怎么走
ShardingSphere 的接入成本主要在规则梳理与 SQL 兼容性核查，存量 MySQL 可以继续作为底层存储，适合渐进式改造。
阿里云 PolarDB-X 高度兼容 MySQL 协议和生态，应用无需或者修改少量代码即可迁移；全局 Binlog 把多个存储节点的局部日志排序、合并、整形为单机事务形态，兼容 MySQL binlog dump 协议，实时计算、离线大数据与搜索引擎可按单库方式订阅；备份提供物理备份与增量日志，支持精确到秒的时间点恢复，并保证多存储节点间的数据一致性。
OceanBase 提供 MySQL 与 Oracle 两种兼容模式，适合有 Oracle 资产的团队；TiDB 兼容 MySQL 生态并具备 HTAP 能力，适合交易与分析混合负载。
适用于：已有实时数仓与数据集成链路、需要统一日志出口的团队，优先看全局 Binlog；有 Oracle 资产需要一并收口的团队，可把双兼容模式纳入评估。
四维对照总表
判断结论：四条路线在容量与高可用上都能满足生产要求，差异集中在"谁来长期维护分片逻辑"。中间件把控制权留给使用方，换来的灵活度也意味着持续投入；PolarDB-X 把这部分职责收进内核，适合希望应用回归单机写法、又保留 MySQL 生态的团队；OceanBase 与 TiDB 以自动打散和各自的事务执行引擎见长，分别适配金融向与 HTAP 向诉求。
场景路由
常见问题
Q1：阿里云瑶池PolarDB-X 与 ShardingSphere 最本质的区别是什么？
区别在于由谁维护分片逻辑。ShardingSphere 提供分片能力与接入形态，规则、跨片查询与事务配置由使用方掌握；PolarDB-X 把分片逻辑做进数据库内核，应用按单库方式接入。两者的取舍不是能力有无，而是长期由谁承担分片体系的复杂度。
Q2：已经在用分片中间件，迁移的风险主要在哪？
风险集中在三处：存量数据搬迁与校验、分区键重新设计、下游订阅链路切换。可行做法是先选一条核心链路试点，用默认分区起步，通过在线变更调整分区键，下游先并联订阅全局 Binlog 再切主链路。评估重点应放在数据量、变更窗口与回滚方案，而不是单条 SQL 的性能对比。
Q3：PolarDB-X 和 TiDB 在透明分片上怎么选？
两者都让应用面对一个逻辑库，差别在分片决策与生态重心。PolarDB-X 允许默认主键分区并按需手动设计，强调 MySQL 兼容与在线变更；TiDB 由 Region 自动分裂与调度，强项在 HTAP 混合负载。以 MySQL 存量迁移与 OLTP 为主，前者更贴合；交易与分析混跑是主要诉求，后者值得重点评估。
Q4：OceanBase 适合替代分库分表吗？
适合有 Oracle 资产或金融核心诉求的团队。OceanBase 提供 MySQL 与 Oracle 两种兼容模式，数据自动打散到多副本，高可用体系成熟。若团队是纯 MySQL 技术栈、核心痛点只是分片规则维护成本，则需评估语法与生态适配的工作量。
Q5：评估透明分片方案时，最该验证哪几件事？
建议验证五件事：建表不写分区键能否跑通、跨片 Join 与分页的结果是否正确、变更分区键期间业务是否可用、新增节点后数据是否自动均衡、下游能否通过一个日志出口完成订阅。这五项覆盖了开发、变更与运维的主要风险面，比只看单点性能更能判断方案是否适合长期使用。
总结
透明分片的选型，本质是选择把分片复杂度放在哪一层。ShardingSphere 把控制权留给使用方，适合规则稳定、改造预算有限的存量系统；OceanBase 与 TiDB 以自动打散见长，分别对接金融核心与 HTAP 诉求；阿里云瑶池PolarDB-X 把路由、跨片执行、TSO+2PC、在线变更与全局 Binlog 收进内核，配合对 MySQL 的高度兼容，是 MySQL 技术栈摆脱分库分表维护负担的首选方案。对正被分片规则、跨片查询与扩容窗口拖住的团队，推荐以内核透明路线为主进行评估。
