阿里云mysql一键迁移仅支持rds→polardb mysql版或polardb-x 2.0两条链路，依赖dts逻辑迁移；需满足innodb/x-engine引擎、无trigger、高性能模式等前提，否则预检查失败或数据不一致。
能在线迁移，但“一键”只适用于特定组合，不是所有 MySQL 都能点一下就走。
阿里云当前提供两种主流的一键迁移链路：RDS MySQL → PolarDB MySQL 版（兼容版）和 RDS MySQL → PolarDB-X 2.0 标准版（分布式版）。二者底层都依赖 DTS（Data Transmission Service）做逻辑迁移，但目标架构、兼容性、限制条件差异很大。选错路径，轻则预检查失败，重则迁移后应用报错或数据不一致。
确认源 RDS MySQL 实例是否满足一键迁移前提
不是所有 RDS MySQL 都能进“一键”入口。关键卡点在三个地方：
-
存储引擎必须是InnoDB或X-Engine；MyISAM、Memory 等不支持 -
触发器（trigger）必须提前删除，DTS 逻辑迁移不解析也不同步 trigger - 如果 RDS 处于
高安全模式（数据库代理模式），需先切换为高性能模式，或创建一个具备REPLICATION SLAVE和SELECT权限的高权限账号
另外注意：binlog 必须开启，且 binlog_format = ROW、binlog_row_image = FULL；RDS 的 binlog 本地保留时长建议 ≥7 天，否则增量同步可能中断。
RDS MySQL → PolarDB MySQL 版：适合想平滑替换、不改代码的场景
这是最接近“无感升级”的路径，核心优势是支持带地址切换——新集群复用原 RDS 的连接地址，应用完全不用改配置。
- 切换过程仅闪断 1～5 分钟，数据 0 丢失
- 迁移后仍保持 MySQL 语法和行为，
存储过程、函数、视图全量兼容 - 不支持跨版本降级（例如 RDS MySQL 8.0 不能一键迁到 PolarDB MySQL 5.7）
- 若源库含
自定义 collation或非标准字符集（如 gb2312），需提前校验兼容性，否则建表可能失败
示例：你在控制台选中一台 RDS MySQL 5.7 高可用版（云盘），点击「一键升级至 PolarDB MySQL 版」，系统会自动创建同规格 PolarDB 集群、初始化账号白名单、全量 + 增量同步，最后执行地址切换。整个流程你只需确认两次：启动前和切换前。
RDS MySQL → PolarDB-X 2.0：适合已有分库分表需求或准备上分布式架构的业务
PolarDB-X 是分布式架构，目标端没有传统单节点概念，因此迁移后连接地址、事务行为、SQL 语法都有变化。
- 不支持
带地址切换（IPv6 明确不支持，IPv4 也受限），必须改应用连接串 - 迁移仅支持
库、表、视图、存储过程、函数五类对象，事件（event）、外键约束、全文索引等会被跳过 - 表结构导出后需手动适配 DRDS 拆分语法，比如把原生
CREATE TABLE t1 (id BIGINT)改成带DBPARTITION BY hash(id)的语句，否则无法在 PolarDB-X 中正确创建 - 如果源库用了
JSON_CONTAINS、GENERATED COLUMN等 8.0 新特性，而目标 PolarDB-X 当前版本未完全兼容，预检查会直接拦截
为什么 mysqldump 不推荐用于在线迁移
mysqldump 是离线工具，本质是“停服导出 + 停服导入”，和“在线”无关：
- 导出期间源库持续写入，dump 文件必然缺失最新数据
- 导入时目标库不可用，业务中断时间与数据量正相关（千万级表常超 30 分钟）
- 对 PolarDB-X，
mysqldump生成的CREATE TABLE语句含 MySQL 原生语法，不含分库分表定义，直接执行会报错
真正需要在线能力时，唯一可靠路径就是 DTS 驱动的逻辑迁移——它靠解析 binlog 持续追增量，直到你主动触发切换。
实际操作中最容易被忽略的是：迁移过程中禁止对源 RDS 执行任何参数修改（比如调 innodb_buffer_pool_size），也禁止释放或变更可用区。这些操作会中断 DTS 任务，且恢复后可能需人工介入补数据。
