mysqldump不能单独用于平滑迁移，因其本质是逻辑快照导出：导出时--single-transaction对InnoDB有效但遇长事务或MyISAM仍锁表；导入为单线程INSERT，10GB数据常需数小时且易报错；函数/存储过程导入失败需额外授权；且不支持增量，无法满足三阶段（结构+全量+增量）平滑迁移要求。
能平滑迁移，但“平滑”不等于零感知——必须配置结构+全量+增量三阶段，且增量通道不手动停用会持续同步，切流后可能覆盖业务写入。
为什么不能只用 mysqldump
mysqldump 本质是逻辑快照导出，天然带阻塞和单点瓶颈：
– 导出时 --single-transaction 对 InnoDB 有效，但遇到长事务或 MyISAM 表仍会锁表或产生不一致快照
– 导入是单线程执行 INSERT，10GB 数据常需数小时，期间业务完全不可写
– 导入后易报错：ERROR 1449 (HY000): The user specified as a definer ('xxx'@'%') does not exist、ERROR 1366 (HY000)（因 RDS 默认开启 STRICT_TRANS_TABLES）
– 函数/存储过程导入失败：RDS 默认关闭 log_bin_trust_function_creators，需提前授权
必须开启的源库 Binlog 配置
DTS 增量迁移依赖 Binlog 实时捕获，以下参数缺一不可，否则预检查直接失败：
– log_bin=ON
– binlog_format=ROW（MIXED 或 STATEMENT 不支持）
– binlog_row_image=FULL
– server_id > 1（若源库已是从库，还需 log_slave_updates=1）
– binlog_expire_logs_seconds ≥ 604800（即 7 天），否则 DTS 拉不到旧位点，任务中断甚至丢数据
修改后需重启 MySQL 或执行 SET PERSIST（MySQL 8.0+），仅 SET GLOBAL 重启即失效
迁移任务配置的三个关键动作
在 DTS 控制台新建任务时，这三项不是可选项，而是启动顺序和行为强约束：
– 结构迁移必须先启用：DTS 自动转换 CREATE TABLE，但会跳过 RDS 不支持的参数（如 ROW_FORMAT=COMPRESSED），外键、全文索引需人工验证是否生效
– 全量迁移启动后，DTS 内部走 SELECT ... INTO OUTFILE + 并行 LOAD DATA，比 mysqldump 快 3–5 倍；注意目标 RDS 必须提前创建空 database，否则报 Unknown database 'xxx'
– 增量迁移必须与全量同时启动：它不是“等全量结束再开始”，而是在全量启动瞬间就接入 Binlog 流；若中途暂停，恢复后会重放已消费过的 event，导致主键冲突
切流前必须验证的隐藏风险点
DTS 控制台显示“迁移完成”只是全量结束、增量延迟归零，不代表可立即切流：
– 抽样校验字段顺序：在源库和 RDS 分别执行 SELECT MD5(GROUP_CONCAT(COLUMN_NAME)) FROM information_schema.COLUMNS WHERE TABLE_SCHEMA='db_name' AND TABLE_NAME='t1'，MD5 不一致说明列序被 DTS 重排（常见于含 TEXT 或 BLOB 列的表）
– 检查 sql_mode 差异：RDS 默认含 STRICT_TRANS_TABLES，而自建库常为宽松模式；应用若存在隐式类型转换（如 INSERT INTO t(id) VALUES('1abc')），切流后直接报错
– 增量通道不会自动断开：切流后若忘记在 DTS 控制台手动停止任务，它仍会把源库后续写入同步到 RDS，覆盖你刚写入的新数据——这是最常被忽略、后果最严重的操作遗漏
