必须用mysqldump做逻辑备份，因其是升级失败后唯一可靠回退方式；需加--single-transaction、--routines、--triggers、--events、--databases及--set-gtid-purged=off/auto和--default-character-set=utf8mb4参数，并验证sql文件头部与尾部完整性及小型库还原测试。
升级前必须用 mysqldump 做逻辑备份
MySQL 升级失败最常导致元数据不兼容或 mysql 系统库损坏，此时物理文件（如 datadir 直接拷贝）往往无法在低版本回退使用。逻辑备份是唯一可靠兜底方式。
实操建议：
- 用
mysqldump --single-transaction --routines --triggers --events --databases db1 db2 > backup.sql，避免锁表且保留存储过程、事件等对象 - 务必加上
--set-gtid-purged=OFF（若未启用 GTID）或--set-gtid-purged=AUTO（若已启用），否则导入时可能报GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty - 不要省略
--default-character-set=utf8mb4，否则中文可能乱码，尤其跨大版本（如 5.7 → 8.0）时字符集默认行为变化明显
mysqldump 备份后必须验证 SQL 文件可读性
备份文件损坏、磁盘写满截断、SSH 中断导致传输不全——这些都会让 backup.sql 看似存在，实则无法恢复。不能只看文件大小或 ls -l。
验证方法：
- 用
head -n 20 backup.sql确认开头有CREATE DATABASE或/*!40101 SET @OLD_CHARACTER_SET_CLIENT=等合法 dump 头部 - 用
tail -n 20 backup.sql检查末尾是否含-- Dump completed on，而不是突然中断的INSERT INTO `table` VALUES - 挑一个小型库做快速还原测试：
mysql -u root -p test_db ，观察是否报错 <code>ERROR 1064或ERROR 1146
别把 mysqldump 当成唯一方案：小库快，大库要换策略
单表超 2GB 或总数据量超 50GB 时，mysqldump 会变慢、内存吃紧，且恢复时间不可控。这时需分场景处理：
- 若用 MySQL 8.0.21+ 且实例支持热备份，优先考虑
mysqlpump（多线程、可并行导出库/表），命令类似mysqlpump --compress --skip-definer --users --all-databases > full.pump - 生产环境核心库建议搭配
Percona XtraBackup做物理备份，但注意：XtraBackup 8.0 版本仅兼容 MySQL 8.0.x，不能用于 5.7 升 8.0 后再回退到 5.7 - 云厂商 RDS 用户直接用控制台「手动备份」功能，它底层调用的是物理快照 + binlog，恢复粒度更细，但跨版本还原仍需确认厂商文档是否支持（例如阿里云 RDS MySQL 5.7 备份不能直接还原到 8.0 实例）
升级失败后恢复，关键不是「怎么导入」而是「怎么选对版本启动」
很多人 dump 恢复失败，其实是没意识到：MySQL 8.0 的 data dictionary 是 InnoDB 表驱动，而 5.7 完全不认识。所以备份只是第一步，回退动作本身有硬性前提。
操作要点：
- 确认你保留了旧版本的
mysqld二进制文件（如/usr/sbin/mysqld-5.7）和对应配置（my.cnf），不能只留数据目录 - 停掉新实例后，改用旧版
mysqld启动，并指定原datadir和干净的socket路径，否则会因系统表结构不匹配直接拒绝启动 - 旧版启动成功后，再用
mysql -u root -p 导入——注意不是覆盖原 <code>datadir，而是清空库后导入，否则触发ERROR 3551 (HY000): The table does not comply with the current server version
最容易被忽略的是：升级前没测试过旧版二进制能否在当前 OS 上运行（比如 CentOS 7 升级 MySQL 8.0 后，glibc 版本变化可能导致 5.7 的 mysqld 启动失败）。这一步必须提前验证。
