MySQL升级后不可直接卸载重装旧版本回滚，因数据字典等可能已被改写；唯一可靠回滚方式是升级前做的合规逻辑备份（含--routines --events --triggers --single-transaction）并导入旧版实例。
MySQL 升级后不能“卸载新版本、重装旧版本”就完事——数据字典、系统表结构、mysql 库权限格式可能已被新版本改写，强行替换二进制或覆盖 datadir 极大概率导致实例启动失败、表无法打开，甚至数据永久损坏。
回滚本质是“用旧版启动一份升级前状态的副本”
官方不支持跨大版本降级（如 8.0 → 5.7），仅对相邻小版本（如 8.0.33 → 8.0.32）提供有限降级能力，且必须满足两个硬性前提：
- 升级后从未启动过新版本 mysqld（或仅以
--skip-grant-tables启动做过只读检查） - 未执行过
mysql_upgrade或等效的mysqld --upgrade=FORCE
一旦新版本已写入数据（哪怕只是执行了一条 INSERT），就必须放弃“覆盖降级”思路，转向备份还原路径。
最可靠回滚：逻辑备份 + 旧版实例导入
这是生产环境唯一可兜底的方案，前提是升级前做了合规的全库导出：
- 导出命令必须含
--routines --events --triggers --single-transaction，否则存储过程、事件、触发器会丢失 - 避免使用
--all-databases直接导出，因sys、performance_schema等库在不同版本间结构不兼容，应单独排除：mysqldump -u root -p --ignore-table=sys.sys_config --ignore-table=performance_schema.* ... - 导入前需用旧版
mysqld启动空实例，并确认default_authentication_plugin与旧环境一致（例如 5.7 默认为mysql_native_password，8.0+ 默认为caching_sha2_password，不匹配会导致用户连不上）
物理备份回滚：XtraBackup / mysqlbackup 解压即用
若升级前用了 Percona XtraBackup 或 MySQL Enterprise Backup，回滚更快，但有版本绑定限制：
- XtraBackup 8.0 备份只能用 XtraBackup 8.0 恢复，且必须匹配 MySQL 主版本（
8.0.x备份不能给8.0.y用，除非 y ≥ x） - 恢复后首次启动时，旧版
mysqld会自动检测并拒绝加载被新版本修改过的表空间；此时必须用--innodb-force-recovery=1启动，再执行mysqldump导出，最后在干净旧实例中导入 - 切勿直接拷贝新版本
ibdata1或ib_logfile*到旧版目录——InnoDB redo log 格式已变更，必然报错InnoDB: Unsupported redo log format
没备份？别碰数据目录，优先尝试修复而非降级
升级失败但尚未写入业务数据时，可抢救性修复：
- 若卡在启动阶段，检查错误日志中是否出现
Table 'mysql.plugin' doesn't exist或Unknown table 'mysql.component'——说明mysql系统库未升级完成，可用升级前备份的mysql库文件（仅此库）覆盖后重试 - 若能连接但查询报错
Incorrect information in file: './db/t1.frm'，大概率是 frm 文件与新版本不兼容，可临时启用innodb_file_per_table=OFF并重建表 - 已写入数据又无备份？不要尝试从新版本导出再删语法——
JSON_TABLE、角色管理语句、隐藏索引定义等 8.0 特有语法无法被 5.7 解析，手动清理极易遗漏，风险远高于停机恢复
真正决定回滚成败的，从来不是操作当天的命令，而是升级前那一次 mysqldump --all-databases --routines --events --triggers > pre_upgrade.sql 是否真实执行并验证过可导入。备份没验证，等于没备份。
