mysqldump是唯一可行起点，因云数据库禁用物理访问、关闭SUPER权限、不可导出系统表空间，必须逻辑导出+本地物理重建；需显式加--single-transaction、--routines等参数，严格对齐字符集与权限体系。
不能直接“迁回”，必须走逻辑导出 + 物理重建流程。云数据库（如阿里云RDS、腾讯云CDB、移动云MySQL）的底层存储和管理机制与本地MySQL不兼容，不存在“挂盘”或“拷贝data目录”这种物理迁移路径。
为什么 mysqldump 是唯一可行的起点
云厂商普遍禁用 SELECT ... INTO OUTFILE、关闭 super 权限、屏蔽 innodb_file_per_table 的裸文件访问，且系统表空间（ibdata1）不可导出。这意味着你无法获取可直接恢复的物理备份文件。
必须依赖逻辑层工具，而 mysqldump 是最可控的选择：
-
--single-transaction必须加，否则 InnoDB 表可能读到不一致快照 -
--routines --triggers --events要显式带上，云环境默认不导出这些对象 - 避免用
--all-databases，云实例常含系统库（如mysql、information_schema），导入会失败 - 若云实例启用了透明数据加密（TDE），导出前需确认目标本地 MySQL 是否支持同版本密钥插件，否则
CREATE TABLE语句里带ENCRYPTION='Y'会报错
字符集与排序规则必须人工对齐
云数据库默认字符集常为 utf8mb4_0900_ai_ci（MySQL 8.0+），而很多本地旧环境仍是 utf8mb4_general_ci 或 latin1。直接导入会导致：
- 建表失败：
Unknown collation: 'utf8mb4_0900_ai_ci' - 字段长度被截断：新排序规则下某些 emoji 占位不同，
VARCHAR(255)实际能存的字符数变少 - ORDER BY / GROUP BY 结果不一致，业务逻辑出错
解决方式不是改源库，而是导出后用 sed 或脚本批量替换：
sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g' backup.sql
同时在目标本地 MySQL 的 my.cnf 中统一设置：
[mysqld]<br>character-set-server = utf8mb4<br>collation-server = utf8mb4_unicode_ci
权限和账号体系要彻底重建
云数据库的账号体系（如 RDS 的 mysql.rds_* 系统用户、只读账号绑定策略、IP 白名单机制）在本地完全无效。你无法直接导入 mysql.user 表。
必须手动重建：
- 用
mysqldump --no-data --databases mysql导出结构，但删掉所有INSERT INTO user语句 - 在本地执行
CREATE USER+GRANT，注意：云环境常见的USAGE权限在本地无意义，应按最小权限原则重授 - 若应用使用了 DEFINER 存储过程，导入时会因用户不存在报错，需先用
--replace或导入后执行ALTER DEFINER
主从复制链路无法复用
云数据库的 binlog 格式常为 ROW，但位置信息（MASTER_LOG_FILE/MASTER_LOG_POS）在导出时已失效；且云实例的 server_id、GTID 设置、半同步参数均与本地环境冲突。
不要尝试用 mysqldump --master-data=2 导出后直接配置从库——它只适用于“云主库 → 云从库”这种同构场景。本地环境必须从零初始化，后续同步靠应用双写或中间件补漏，而非原生复制。
真正容易被忽略的是时间点一致性：云实例导出耗时若超过几分钟，业务持续写入就会导致部分事务丢失。务必在业务低峰期操作，并在导出前后记录 SHOW MASTER STATUS 和 SELECT NOW()，用于后续比对延迟范围。
