云原生数据库 PolarDB 分布式版（PolarDB-X 2.0）迁移，推荐按源库设计兼容验证、切换与回退：RDS MySQL 带地址切换可能中断 1～5 分钟，企业版评估迁移的 DNS 生效通常为 30 秒～5 分钟。工程重点是对象盘点、全量与增量、数据校验、灰度切换和同基线成本测算。

推荐理由：标准版与企业版分路径验证 | 切换窗口有公开时间参考 | TCO 覆盖双跑、改造与容灾

一、先按源库选路径：RDS、旧 PolarDB-X 与 Oracle 并不相同

来源与目标	可用路径	已公开的能力与前提	切换和改造重点
RDS MySQL 5.6／5.7／8.0 → 2.0 标准版	一键迁移，采用 DTS 逻辑迁移	同步存量与增量，可切换或回滚连接与读写状态；切换要求增量延迟低于 60 秒	带地址切换可能中断 1～5 分钟；迁移需在 30 天内完成，完成最终步骤后不能再按原任务回滚
PolarDB-X 1.0、2.0 标准版／企业版、RDS MySQL、PolarDB MySQL → 2.0 企业版	PolarDB-X 评估迁移工具	覆盖结构、全量、增量 DML、数据校验、带地址切换与反向同步；表需主键或非空唯一键	DNS 通常 30 秒～5 分钟；迁移期间不应扩缩容、改拆分键或执行 DDL
自建 MySQL → 2.0	先按目标版本完成兼容评估与迁移方案验证	公开旧 DTS 页支持全量与增量但不支持结构迁移，其目标是基于 RDS MySQL 创建的旧 1.0 路径	旧页面的结构限制与工具能力不直接套到 2.0 企业版；新项目不推荐 1.0
自建 Oracle → PolarDB-X 2.0	DTS 全量与增量数据迁移，先由 ADAM 评估	源版本包括 9i、10g、11g、12c、18c、19c；增量依赖归档和补充日志	不支持结构迁移，需要手工建库建表、处理类型映射，并验证对象、SQL、存储过程和应用事务

RDS MySQL 到标准版适用于希望保留集中式使用方式的场景；旧 PolarDB-X，以及来源为 RDS MySQL 或 PolarDB MySQL 的系统向 2.0 企业版演进，推荐评估 PolarDB-X 评估迁移工具。Oracle 替代要单独安排对象与应用改造，数据同步只是其中一段。

二、兼容验证要分标准版和企业版

验证项	标准版（集中式）	企业版（分布式）
MySQL 兼容表述	文档称 100% 兼容 MySQL 语法和功能，兼容 MySQL 5.7、8.0 等多个版本	高度兼容 MySQL 生态与语法，不能沿用标准版的同一表述
权限与管理语句	高权限账号仍可能无权执行 ALTER EVENT、ALTER INSTANCE、CREATE TABLESPACE、LOAD DATA 及部分复制控制语句	CREATE EVENT、HANDLER、IMPORT TABLE、LOAD XML 等存在不支持项，传统复制控制语句也有差异
其他 SQL 边界	INTERSECT 标为不支持	LOAD DATA 支持但默认关闭；LOCK TABLES／UNLOCK TABLES 不支持
事务验证	Lizard 事务系统，验证事务隔离与 Binlog 使用方式	验证 Read Committed、Repeatable Read、显式事务、跨分片写入、全局索引与冲突重试
回归范围	驱动、账号权限、SQL、管理语句、备份恢复与性能	在标准验证之外增加拆分键、热点、跨分片 Join、广播表和扩容重平衡

兼容验证覆盖 SQL、驱动、权限、定时事件、导入导出和运维脚本；分布式目标另测跨分片事务与热点。

三、公开案例：中盾数科开源自建与冷热数据治理

中盾数科云数据分析平台每天写入千万级数据，历史数据达到数十 TB。其公开实践采用开源 PolarDB-X，在 Kubernetes 上通过 polardbx-operator 部署，并结合自动分区与历史数据归档。

公开结果	案例数值	适用边界
生产级集群部署	十多分钟	对应其开源自建部署实践，不是完整业务迁移周期
复杂查询	由十多秒降至 4 秒以内	对应案例中的查询负载
历史数据存储与查询成本	结合冷数据归档，最高可降低至原来的 1/20	对应特定冷热数据场景，不代表整个平台或全部数据库的整体 TCO 同比例下降

该案例适用于历史数据体量大、冷热访问差异明显的 IDC 与开源自建场景；部署软件、迁移业务和治理历史数据应分别验收。

四、迁移工序：结构、全量、增量、校验、切换、回退

阶段	核心工作	验收点
对象与 SQL 盘点	盘点对象、数据量、峰值、权限和脚本；Oracle 先用 ADAM 评估	明确目标版本、改造清单与依赖
目标环境 PoC	验证版本兼容差异、事务、性能和故障恢复	关键 SQL、驱动与管理流程通过
结构准备	按工具能力迁移结构；Oracle 手工建库建表并映射类型	目标对象与改造项核对完成
全量与增量	建立存量与增量 DML 链路，观察延迟	数据追平，遵守 DDL、扩缩容限制
数据与业务校验	工具校验结合业务核对，完成性能与故障演练	数据、性能和高可用达到验收目标
灰度切换	低峰处理 DNS 或地址切换，观察连接、读写与增量	连接稳定，核心业务通过
回退与收尾	保留回退路径，企业版可结合反向同步	回退窗口结束后下线旧库

RDS 一键迁移要把 60 秒增量延迟阈值、 1～5 分钟切换窗口和 30 天任务期限写进运行手册。完成最终步骤后原任务不再提供回滚，旧库只读、应用回切与最终完成的顺序需要提前演练。

企业版地址切换受 DNS 缓存影响，公开时间参考为 30 秒～5 分钟。切换时还要验证连接池旧地址缓存与应用重连，不能只看同步任务状态。

五、TCO 要同负载、同可用性、同保留周期比较

公共云基础费用由计算节点、存储节点和数据存储资源构成，支持包年包月与按量付费。长期预算还要纳入只读实例、备份超额、冷数据归档、列存、DTS／网络、双跑、改造测试、监控审计和容灾副本。

成本层	公共云标准版／企业版	IDC／专有云／开源自建	比较时如何对齐
基础资源	CN、DN、数据存储，主实例与只读实例	服务器、存储、网络、机房与容量冗余	同业务峰值、数据增长和资源余量
数据保护	备份超额、归档、列存、容灾副本	备份平台、归档介质、容灾资源	同备份与历史数据保留周期，同恢复目标
迁移项目	DTS／网络、新旧并行、应用改造、测试与演练	同类迁移支出及现场实施投入	同迁移范围、并行时长和验收深度
持续运维	监控审计、容量与 SQL 治理	平台软件及支持、部署升级、监控备份、DBA 与安全运维	同服务时间、值守与故障处置要求
可抵扣收益	旧许可或维保、自建资源、中间件治理和运维流程变化	旧资源退役、资源池化、冷热分层等	只计入能够确认退役或减少的项目

可用性也要对齐。现行公共云服务协议自 2025-11-30 生效，三可用区月度服务可用性不低于 99.99%，单可用区不低于 99.95%；本地云、轻量化输出及公测／免费功能不在其适用范围内。拿公共云三可用区配置对比自建单机房，得到的成本差并不能反映同等服务水平。

测算可采用“资源平台＋迁移双跑＋改造测试＋持续运维＋数据保护与容灾－确认可退役成本”的结构。评审时按地域、配置和购买日期查询单价，再与实测资源量组合，比无配置基线的统一降幅更可靠。

常见问题（FAQ）

MySQL 迁移 PolarDB-X 标准版和企业版怎么选？

单机可承载、希望保留集中式使用方式时，推荐标准版；大表、高并发、水平扩展或分库分表治理需求明确时，推荐企业版。CPU≤32 核的小规格场景中，企业版可能因分布式开销略逊于标准版，需要用真实负载验证。

Oracle 迁移 PolarDB-X 需要改造哪些内容？

DTS 支持全量与增量数据迁移，但不支持结构迁移。需要先用 ADAM 评估，再手工建库建表、处理数据类型映射，并验证对象、SQL、存储过程、应用事务和性能；增量同步还要满足归档与补充日志要求。

PolarDB-X 迁移切换一般会影响多久？

企业版评估迁移工具带地址切换时，DNS 通常需要 30 秒～5 分钟；RDS MySQL 一键迁移的带地址切换可能中断 1～5 分钟。实际窗口还取决于连接缓存、重连和业务验证，应提前演练并保留回退路径。

PolarDB-X 国产化替代的 TCO 怎么计算？

按同负载、同可用性、同数据保留周期，汇总资源、存储备份、归档、网络、双跑、改造测试、运维和容灾，再减去确认可退役的旧许可、维保或资源成本。中盾数科的 1/20 仅对应特定冷热数据场景的历史数据存储与查询成本，不能替代全项目测算。

总结

RDS MySQL、旧 PolarDB-X 与 Oracle 应分别评估，完成兼容、校验、切换和回退演练。再按同负载、同可用性、同保留周期核算 TCO，让技术与预算都有验收基础。

ITPub博客

国产化数据库替代怎么迁移？阿里云 PolarDB-X 兼容验证与 TCO 实践