结论是：没有真正“无缝”的迁移，但通过dts+增量同步可将停机压缩至分钟级；dts必须配置结构、全量、增量三类迁移并按序启动，而mysqldump因写入阻塞、单线程导入、权限字符集等问题不适合作为主力迁移工具。
所谓“无缝”，实际是指业务不停服、数据不丢、主键不冲突、连接自动切流。这需要绕过 mysqldump 这类全量逻辑导出的天然停写缺陷，转而依赖具备实时捕获能力的中间件。阿里云 DTS 是目前最成熟、适配 RDS 的方案。
为什么不用 mysqldump 做主力迁移
mysqldump 导出时需加 --single-transaction（仅对 InnoDB 有效），但无法规避以下硬伤：
- 导出期间源库写入被阻塞或产生不一致快照（尤其含 MyISAM 表或长事务）
- 导入过程单线程瓶颈明显，10GB 以上数据耗时数小时，期间业务完全不可写
- 导入后需手动处理
DEFINER、存储过程权限、时区/字符集差异，容易报ERROR 1449 (HY000): The user specified as a definer ('xxx'@'%') does not exist - RDS 默认关闭
log_bin_trust_function_creators，导入含函数的 SQL 会失败
DTS 迁移必须配置的三项类型
结构迁移、全量迁移、增量迁移三者缺一不可，且必须按序启动：
-
结构迁移：自动转换
CREATE TABLE语句，跳过 RDS 不支持的参数（如ROW_FORMAT=COMPRESSED），但需人工检查外键和全文索引是否生效 -
全量迁移：DTS 内部用
SELECT ... INTO OUTFILE+ 并行 LOAD，比mysqldump快 3–5 倍；注意目标库需提前创建空 schema，否则报Unknown database 'xxx' -
增量迁移：依赖源库开启
binlog（格式必须为ROW），DTS 实时拉取并重放 event；若源库binlog_expire_logs_seconds设置过短（如
切换前必须验证的三个细节
哪怕 DTS 控制台显示“迁移完成”，也不能直接切流量：
- 对比源库与 RDS 的
SELECT COUNT(*) FROM information_schema.tables，确认表数量一致；再抽样查SELECT MD5(GROUP_CONCAT(COLUMN_NAME)) FROM information_schema.COLUMNS WHERE TABLE_SCHEMA='db_name'验证字段顺序 - 执行
SHOW MASTER STATUS（源库）和SHOW SLAVE STATUS\G（RDS 上 DTS 创建的临时复制通道），确认Seconds_Behind_Master为 0 且无IO_Running/SQL_Running报错 - 在 RDS 上执行
SELECT @@sql_mode，若返回含STRICT_TRANS_TABLES，而应用代码存在隐式类型转换（如字符串插入数字字段），会触发ERROR 1366 (HY000)
最容易被忽略的是：DTS 增量通道在切换后不会自动断开，它会持续同步直到你手动停止任务。若忘记停，后续源库误操作仍会污染 RDS 数据。
