删除备份SQL文件中SET @@GLOBAL.GTID_PURGED=语句，导出时用--set-gtid-purged=OFF，phpMyAdmin导入取消勾选“执行SET语句”；恢复后执行RESET SLAVE ALL重置只读实例GTID状态；大文件改用mysql命令行导入。
恢复时提示 ERROR 1840 (HY000)：GTID 已启用但 @@GLOBAL.GTID_PURGED 不为空
这是阿里云 rds 备份恢复最常卡住的地方。rds 默认开启 gtid，而你用 mysqldump 导出的逻辑备份（尤其带 --set-gtid-purged=on）会在 sql 文件开头写入类似 set @@global.gtid_purged='xxx-xxx-xxx'; 的语句——但 rds 不允许直接 set 这个变量，会直接报错中断导入。
实操建议：
- 用文本编辑器打开备份 SQL 文件，删掉所有以
SET @@GLOBAL.GTID_PURGED=开头的行（通常只有一行，在文件最前面） - 如果备份是用
mysqldump --set-gtid-purged=AUTO生成的，下次导出请改用--set-gtid-purged=OFF，避免写入该语句 - phpMyAdmin 导入时不要勾选「执行
SET语句」选项（它默认不勾选，但确认下更稳妥）
导入后数据存在但主从复制异常：RDS 只读实例同步中断
阿里云 RDS 主实例恢复逻辑备份后，gtid_executed 和 gtid_purged 并未自动重置，导致只读实例无法从新起点拉取 binlog，表现为延迟飙升或 Slave_SQL_Running: No。
实操建议：
- 登录 RDS 主实例，执行
SHOW MASTER STATUS;确认当前 binlog 文件和 position - 在只读实例上执行
STOP SLAVE;→RESET SLAVE ALL;→START SLAVE;（注意：不是RESET SLAVE，必须加ALL才清空 GTID 相关状态） - 检查
SHOW SLAVE STATUS\G中的Retrieved_Gtid_Set和Executed_Gtid_Set是否开始增长
phpMyAdmin 导入超时或失败：大备份文件根本传不上去
阿里云 RDS 的 phpMyAdmin 是托管界面，上传限制极严：upload_max_filesize 通常仅 2MB，且无权修改配置。超过这个大小的备份（比如几百 MB 的库）点上传就静默失败或提示 File upload error。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 别用 phpMyAdmin 传大文件——它不是干这个的
- 改用命令行：本地装 MySQL 客户端，用
mysql -h your-rds-endpoint -P 3306 -u user -p database_name - 若必须走 Web 界面，先用
split -l 1000 backup.sql part_拆分（按行数切），再逐个导入；但要注意外键和事务边界，慎用于含大量INSERT的文件
恢复后部分表缺失或乱码：字符集与排序规则不匹配
阿里云 RDS 默认字符集是 utf8mb4，但老备份可能用 utf8（MySQL 的 utf8 实为 utf8mb3），或导出时没指定 --default-character-set=utf8mb4，导致中文字段变成问号或截断。
实操建议：
- 导入前在 SQL 文件头部手动添加
SET NAMES utf8mb4;（放在第一个USE语句之后、建表之前） - 检查建表语句中是否有
CHARSET=utf8或COLLATE=utf8_general_ci，批量替换成utf8mb4和utf8mb4_unicode_ci - 导入完成后执行
SELECT DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = 'your_db';确认库级默认排序规则
GTID 状态、权限隔离、字符集、导入通道——这四块不提前对齐，恢复动作大概率半途崩掉。尤其是 RDS 的权限模型和自建 MySQL 不同，root 用户在 RDS 里其实是个受限账号，很多 SET GLOBAL 类操作直接被禁止，得换思路绕过去。
