升级前必须用 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 启动失败）。这一步必须提前验证。
