MySQL升级后不可直接卸载重装旧版本，因数据字典、系统库结构、InnoDB redo log格式等已被新版本改写；唯一可行回滚路径是用旧版mysqld启动升级前备份的干净副本并切流，且备份须满足：①导出含--routines --events --triggers --single-transaction；②排除sys和performance_schema库；③导入目标为匹配default_authentication_plugin的旧版实例。
MySQL升级后不能直接卸载重装旧版本
升级后的MySQL实例，数据字典、mysql系统库结构、InnoDB redo log格式、权限表字段（如authentication_string哈希方式）、甚至default_authentication_plugin默认值都可能已被新版本改写。强行卸载新二进制、重装旧版、再启动——大概率报错InnoDB: Unsupported redo log format或Table 'mysql.component' doesn't exist，实例根本起不来，甚至损坏表空间。
真正能落地的回滚，只有一条路：用旧版本 mysqld 启动一份「升级前状态」的干净副本，再把业务流量切过去。这要求你升级前就做好了合规备份。
回滚依赖的备份必须满足三个硬性条件
不是随便一个mysqldump就能救急。以下三点缺一不可，否则导入后会丢存储过程、触发器、事件，或因字符集/权限问题连不上：
- 导出命令必须带
--routines --events --triggers --single-transaction，否则mysql.proc、mysql.event等元数据全丢 - 不能用
--all-databases直接导，要排除不兼容库：--ignore-table=sys.sys_config --ignore-table=performance_schema.* - 导入目标必须是旧版本 mysqld 实例，且配置中
default_authentication_plugin要匹配（例如 MySQL 5.7 是mysql_native_password，8.0+ 默认是caching_sha2_password）
物理备份（XtraBackup）恢复更快，但有版本锁死风险
如果你用了 Percona XtraBackup，回滚速度远超逻辑导入，但必须严格对齐版本：
-
XtraBackup 8.0.33备份只能用XtraBackup 8.0.33（或更高小版本）恢复，不能跨到8.0.32 - 恢复后首次启动，旧版 mysqld 会拒绝加载被新版本修改过的表空间，此时需加
--innodb-force-recovery=1启动，再用mysqldump导出，最后导入干净旧实例 - 绝对不要手动拷贝
ibdata1或ib_logfile*到旧版 datadir——redo log 格式已变，必然失败
没备份？别碰数据目录，优先抢救性修复
升级失败但尚未写入业务数据时，还有微弱抢救机会；一旦执行过任何 INSERT 或 mysql_upgrade，就彻底放弃“覆盖降级”幻想：
- 若卡在启动阶段，错误日志出现
Unknown table 'mysql.component'，说明系统库升级中断，可尝试用升级前备份的整个mysql库文件覆盖当前mysql子目录（仅此库） - 若已启动并写入，唯一现实路径是：停服务 → 用旧版 mysqld + 备份 datadir 启动 → 验证 → 切流。没有备份，就没有回滚，只有重建
- GTID 已启用的环境更危险：
GTID_MODE = OFF_PERMISSIVE不兼容低版本，mysqld甚至无法启动，此时改auto.cnf或清gtid_executed都救不回数据
最常被忽略的点：回滚不是技术动作，而是流程动作。它依赖升级前是否保留了旧版二进制、my.cnf、datadir 快照，以及是否在测试环境跑通过完整回滚链路。这些准备没做，故障时所有“方案”都是纸上谈兵。
