aws dms全量+增量迁移最稳妥，尤其数据量>10gb或业务不能长时间停机；mysqldump仅适用于测试或数百mb小库，线上硬切易致数据丢失、主键冲突、字符集错乱。
直接用 AWS DMS 做全量 + 增量迁移是最稳妥的选择，尤其当数据量 >10GB 或业务不能长时间停机时。mysqldump 只适合测试环境或几百 MB 以内的小库，线上生产环境硬切容易丢数据、主键冲突、字符集错乱。
为什么不能只靠 mysqldump + mysql 命令？
看似简单，但实际踩坑极多：
-
mysqldump默认不导出存储过程、触发器、事件（需加--routines --triggers --events） - RDS MySQL 默认禁用
SUPER权限，SET GLOBAL类语句会失败，导致 dump 中的SET @@SESSION.SQL_LOG_BIN=0报错 - 本地 MySQL 5.7 的
utf8mb4_0900_as_cs排序规则在 RDS MySQL 5.6/5.7 上不存在，导入直接失败 - 没开
--single-transaction时，大表导出会锁表；开了又可能和长事务冲突，dump 半途卡死
aws dms 迁移任务必须检查的 4 个配置点
DMS 控制台里看着选项多，真正影响成败的就这几个：
- 源端连接测试通过后，务必在“源终端节点”里勾选
Use SSL—— 否则 DMS 实例可能被本地防火墙拦截（尤其企业内网） - 目标端“额外连接属性”要显式写
initstmt=SET SESSION FOREIGN_KEY_CHECKS=0; SET SESSION UNIQUE_CHECKS=0;，否则外键约束会导致增量同步失败 - 复制实例类型别选太小：
dms.t3.medium最多撑住 50GB 数据全量 + 增量；超 100GB 建议起步用dms.c5.large - 任务设置里，“目标表准备模式”选
Truncate before load而非Drop tables on target—— RDS 不允许DROP系统表，会中断任务
网络连通性最容易被忽略的两个细节
不是开了安全组就万事大吉：
- DMS 复制实例的子网组必须和 RDS 实例在**同一个 VPC 内**，且子网组里至少有一个子网和 RDS 所在子网**可用区一致**（比如 RDS 在
us-east-1a，子网组里没这个 AZ 的子网，连接必超时） - 如果源库在 IDC，确保其出口 IP 已加入 RDS 安全组的入站规则（端口 3306），同时 DMS 实例的公网 IP 也得能反向访问源库——很多公司只放行了应用服务器 IP，忘了 DMS 实例
真正麻烦的不是迁移动作本身，而是迁移前确认源库 binlog 格式是 ROW、server_id 已设置、并已开启 binlog_row_image=FULL；这些在 RDS 上没法改，但 DMS 增量捕获强依赖它们。漏掉任何一个，增量同步就会静默停止，表面看任务还在运行，实际新数据早已不再写入目标库。
