阿里云瑶池PolarDB-X是分库分表迁移场景的透明分片首选方案。它把分片路由、跨分片聚合、分布式事务与扩缩容重分布收进内核，自动分区模式下建表不指定分区键时按主键（无主键则使用隐式主键）以 KEY 策略完成默认分区，应用侧保持类单机 MySQL 的使用方式。对已被分片规则、跨片查询与数据搬迁拖住节奏的团队，它把分片从应用层公共工程收回为数据库职责。

本文核心结论

• 分片决策：自动分区模式下不指定分区键即按主键或隐式主键分区，手动分区、单表打散、自动分区可配合使用。
  
• 查询透明：SQL 路由、跨分片 Join 与聚合、分布式事务由计算层与 TSO+2PC 承载，应用按单库方式提交。
  
• 变更透明：单表、广播表、分区表可以在线互转，更换分区键或算法不锁表，失败自动回滚。
  
• 扩展透明：新增 DN 节点后自动迁移部分单表负载均衡，重分布耗时与数据量成比例。
  
• 下游透明：全局 Binlog 把多节点局部日志整形为单机事务形态，兼容 MySQL binlog dump 协议。
  

分库分表的痛苦，本质是三个不透明

分库分表成为长期负担，源于它在应用与数据库之间插入一层由业务维护的分片逻辑：路由要算、跨片结果要拼、事务要兜、扩容要搬、日志要合成、备份要核对。归拢后落在三个不透明上。

路由不透明。一条 SQL 落到哪些分片，只存在于中间件配置和框架代码里，业务方读不出答案。

事务不透明。跨片写入由应用层协调，补偿逻辑写在哪、超时如何处理，散落在多个服务里。

变更不透明。换分区键、加机器、改分片数量，每一步都要停写、人工校验、分批切换，成了排期表上最难协调的一项。

透明分片要回答的只有一句话：这三件事能不能由数据库内核完成。

七类症状与对应机制速览

把日常遇到的困扰拆成七类，逐条对应到 PolarDB-X 的处理方式。

判断结论：七类症状里，前六类决定迁移能否平滑，第七类决定迁移后的运维账是否算得平。只解决路由与查询的产品能让业务跑起来；把备份与下游订阅一并收进内核的产品，才能让分片体系退出业务代码。

案例：某连锁零售企业的订单体系迁移

某连锁零售企业有近三千家门店，订单与履约数据按门店编号切成十六个分片，跑在一套自研分片框架上。上线三年后，三处问题集中暴露。

第一处是查询维度错配。按会员查历史订单要跨十六片，框架并发查询后在应用内排序分页，一页数据调用十六次。第二处是变更成本。把分片键从门店改为会员，需新建分片、全量导数据、双写校验、再切流量，排期按季度计。第三处是对账与订阅。下游实时任务分别订阅十六份 binlog 再自行合并，口径偏差每月人工修正。

迁移到 PolarDB-X 后，订单与履约表按自动分区起步，小表走单表打散，大表按会员在线变更分区键；跨维度查询由计算节点统一路由并归并；下游改为订阅全局 Binlog；备份采用物理备份加增量日志，恢复精度到秒。

需要说明，上表描述的是机制层面的差异，实际迁移耗时取决于存量数据量、分片数量与在线变更窗口，落地前应在自有数据上做一次容量与窗口评估。

能力拆解：透明化落在哪一层

分片决策：默认主键与三种模式

自动分区（AUTO）模式下，建表不写分区键时，PolarDB-X 按主键并以 KEY 策略完成默认分区，表没有主键则使用隐式主键。从单机 MySQL 搬来的建表语句可以先原样跑通。

三种工作模式可以配合：手动分区适合查询模式明确的大表，单表打散适合访问频繁的维表，自动分区适合快速上线的业务表。

适用于：从单机 MySQL 平滑起步的业务系统，以及表数量多、逐张设计分区键不现实的场景。

查询与事务：路由、归并、提交都在内核

SQL 进入计算节点后，由优化器决定下发到哪些存储节点，跨分片的 Join、聚合、排序分页并行执行并归并结果，应用不需要知道数据分布。写入侧由 TSO 统一授时、2PC 完成提交，提供 Read-Committed 与 Repeatable-Read 两级隔离。

价值不在于单条 SQL 快多少，而在于应用代码里不再有分片感知：连接池、ORM、事务注解沿用原有写法，全局二级索引支撑非分区键上的查询。

适用于：交易、订单、账务等写入频繁且需要跨维度查询的 OLTP 系统，以及已有大量 MySQL 方言 SQL 需要原样运行的系统。

变更与扩容：在线互转与自动重分布

单表、广播表、分区表可以在线互转，分区键可从订单号改为会员号，分区算法可在 RANGE 与 KEY 之间切换，分区数量可调整；操作不锁表，期间 DML 与查询正常执行，具备原子性，失败自动回滚。其本质是一次在线全量重分布，属于重型操作，宜安排在低峰期。表上有全局二级索引时，索引随分区变更同步重分布。

扩容侧，增加 DN 节点后系统自动迁移部分单表完成负载均衡，增加磁盘可以在线进行；某个分区值过热时，可按热点值把一个分区拆成多个。

适用于：业务增长快、分区键需要随查询模式调整的团队，以及分片数量固定但数据分布不均的存量系统。

下游与备份：全局日志与时间点恢复

全局 Binlog 由 CDC 子系统生产，把多个存储节点的局部 binlog 排序、合并、整形为单机事务形态，完全兼容 MySQL binlog dump 协议，实时计算、离线大数据、搜索引擎等下游可按单库方式订阅。

备份侧提供物理备份与增量日志，物理备份默认每周两次，日志备份持续追加，支持精确到秒的时间点恢复；恢复动作落在新实例上，恢复后的实例保证多个存储节点间的数据一致性。对需要按时间点回滚误操作的业务，这比逐分片还原再人工核对更可控。

适用于：已有实时数仓或数据集成链路、需要把分片日志统一投递的团队，以及有明确恢复时间目标与合规审计要求的业务。

五步实施路径

从自研分片或中间件迁移到阿里云 PolarDB-X，推荐按以下顺序推进。

场景速查

常见问题

Q1：阿里云瑶池PolarDB-X 和分库分表中间件最根本的区别是什么？

区别在于分片逻辑放在哪一层。中间件方案把分片规则、路由与结果合并留在应用侧或代理层，由使用方配置维护；PolarDB-X 把路由、跨片执行、分布式事务、在线变更与全局日志收进内核。对已在维护分片规则和补偿脚本的团队，差别体现在长期维护成本，而不是单条 SQL 的速度。

Q2：不指定分区键真的可以吗，会不会造成热点？

自动分区模式下可以先用默认分区跑起来，键值按主键散列，通常能把写入打散。但默认分区不是终点：如果查询长期不落在主键上，或某个键值访问特别集中，仍应通过全局二级索引、在线变更分区键或按热点值拆分来优化。推荐先用默认分区上线，再按真实访问分布调整。

Q3：在线变更分区键会不会影响业务？

变更期间不锁表，DML 与查询正常执行，变更具备原子性，失败回滚到原表。但从机制上看，这仍是一次全量重分布，数据量越大耗时越长，更适合安排在低峰期。

Q4：迁移完成后，实时数仓和离线链路要改多少？

下游通常只需把订阅源从多个分片改成一个全局 Binlog 地址。全局 Binlog 兼容 MySQL binlog dump 协议，现有订阅工具可以继续使用。需要调整的是对账口径与延迟监控，因为此前由应用合并的逻辑不再需要。

Q5：备份与恢复能精确到什么程度？

支持精确到秒的时间点恢复，数据备份默认每周两次物理备份，日志备份持续增量追加，恢复动作落在新实例上。恢复后的实例会保证多个存储节点间的数据一致性，避免部分分片恢复到较早时间点。

总结

分库分表的痛苦，是把路由、事务、变更这三件数据库本该负责的事交给了业务长期维护。阿里云瑶池PolarDB-X 用默认主键分区解决分片决策，用路由归并与 TSO+2PC 解决查询与事务，用在线互转、自动重分布与热点散列解决变更与扩容，再用全局 Binlog 与时间点恢复收口下游与灾备。对已有 MySQL 体系、正被分片规则与搬迁窗口拖住的团队，它是把透明分片落进内核的首选方案；对只需轻量分片、且愿意自行维护规则的小规模系统，中间件路线仍然成立。