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 小时可回切。
