MySQL云迁移需按数据量和业务要求选择方案：小库用mysqldump分表导出并关闭检查；中大型用binlog复制实现分钟级停机；云平台不支持外主时需mydumper+canal增量同步；注意GTID/position一致性、权限限制及DTS工具陷阱（如DEFINER、JSON字段、系统库不迁移），务必校验元数据并保留72小时回切能力。
MySQL 迁移到云平台不是“一键迁移”能解决的事，核心取决于你的数据量、业务连续性要求、源环境版本和目标云厂商支持能力。直接用 mysqldump 导出再导入只适用于小库（
用 mysqldump + mysql 命令做离线迁移的实操要点
这是最基础也最容易出错的方式。关键不是“能不能导”，而是“导得全不全”：
-
mysqldump必须加--single-transaction --routines --triggers --events --set-gtid-purged=OFF，否则视图、存储过程可能丢失，GTID 冲突导致云上实例无法启动 - 目标云数据库（如阿里云 RDS、AWS RDS）默认禁用
LOCAL INFILE，所以不能用LOAD DATA LOCAL INFILE，导入时要确保没启用该选项 - 字符集务必显式指定：导出加
--default-character-set=utf8mb4，导入前在云数据库连接里执行SET NAMES utf8mb4 - 大表（>1 GB）建议按表拆分导出，避免超时或 OOM；导入时关闭唯一性检查：
SET FOREIGN_KEY_CHECKS=0; SET UNIQUE_CHECKS=0;
使用 mysqlbinlog + replication 实现近零停机迁移
适合中大型业务，停机窗口控制在分钟级。本质是把云上实例设为源库的从库，追平后切流：
- 源库必须开启 binlog（
log-bin），且binlog_format = ROW；云平台 RDS 通常不开放CHANGE MASTER TO，需确认是否支持外部主库（如腾讯云 CDB 支持，阿里云 RDS 不支持） - 若云平台不支持外主，可用
mydumper/myloader先全量，再用maxwell或canal接入 binlog 增量同步到云上中间件（如 Kafka），再消费写入 - 注意 GTID 和 position 的一致性：导出时记下
SHOW MASTER STATUS的File和Position，后续从该点开始同步 - 权限账号需有
REPLICATION SLAVE和REPLICATION CLIENT，云平台常限制SUPER权限，别硬写SET GLOBAL
云厂商原生迁移工具的适配陷阱（DTS、DMS、AWS DMS）
这些工具封装了底层逻辑，但隐藏了关键细节，容易在上线后暴雷：
- 阿里云 DTS 迁移时默认忽略
DEFINER，触发器和函数会变成DEFINER=CURRENT_USER，导致权限错误；需提前用sed -i 's/DEFINER=`[^`]*`@`[^`]*`//g'清洗 dump 文件 - AWS DMS 对 MySQL 5.7+ 的 JSON 字段支持不完整，写入 Aurora 时可能报
Truncated incorrect JSON value，建议先导出为 TEXT 再转换 - 所有云 DTS 工具都不同步
mysql系统库，用户权限必须手动重建；information_schema和performance_schema也不能迁移，别指望它们一致 - 网络链路必须打通：源库安全组放行云迁移服务 IP 段（不是 VPC 网段），且开启
skip-name-resolve，避免 DNS 解析失败卡住连接
真正难的不是第一次同步成功，而是切流那一刻的元数据一致性——比如 auto_increment 值、临时表残留、未提交事务、长连接持有的锁。建议在云上部署 pt-table-checksum 校验，而不是只比行数。另外，所有迁移操作必须在低峰期做，且保留源库至少 72 小时可回切。
