回滚不是卸载重装，而是用旧版mysqld启动升级前合规备份并切流；备份须满足：①导出含--routines --events --triggers --single-transaction；②排除sys和performance_schema库；③导入目标为default_authentication_plugin匹配的旧版实例。
回滚不是“卸载重装”，而是用旧版启动备份副本
MySQL升级后不能直接卸载新版本、再装旧版本——mysql.component表缺失、InnoDB: Unsupported redo log format、authentication_string哈希不兼容等错误几乎必然出现。真正能落地的回滚，只有一条路径：用旧版本 mysqld 启动一份升级前状态的干净数据副本，再把流量切过去。这意味着回滚动作本身不依赖新版本能否“降级”，而完全取决于你有没有一份合规的备份+可用的旧版二进制。
备份必须满足三个硬性条件，缺一不可
随便一个 mysqldump --all-databases 导出根本救不了急。以下三点是回滚成功的底线：
- 导出命令必须带
--routines --events --triggers --single-transaction，否则存储过程、事件、触发器全丢 - 必须显式排除不兼容库：
--ignore-table=sys.* --ignore-table=performance_schema.*，这两个库结构在 8.0+ 有重大变更，导入旧版会报错 - 导入目标必须是旧版本
mysqld实例，且default_authentication_plugin配置要匹配（例如 MySQL 5.7 必须设为mysql_native_password，8.0+ 默认是caching_sha2_password）
物理备份（XtraBackup）快但有版本锁死风险
如果你用了 Percona XtraBackup，恢复速度远超逻辑导入，但代价是强绑定版本：
- 备份只能用 XtraBackup 8.0.33（或更高小版本）恢复，不能跨到更低小版本
- 恢复后首次启动，旧版
mysqld会拒绝加载被新版本写过的表空间，此时需加--innodb-force-recovery=1启动，导出逻辑 SQL，再导入干净旧实例 - 绝对不要手动拷贝
ibdata1或ib_logfile*到旧版datadir——redo log 格式已变，必然失败
没备份时的抢救窗口极窄，别赌运气
升级失败但尚未写入业务数据时，还有微弱抢救机会；一旦执行过任何 INSERT 或 mysql_upgrade，就彻底放弃“覆盖降级”幻想：
- 若卡在启动阶段，错误日志出现
Unknown table 'mysql.component'，可尝试用升级前备份的整个mysql库文件覆盖当前mysql子目录（仅此库） - 若已启动并写入数据，唯一可行路径是：从新版本实例导出逻辑 SQL（
mysqldump --no-tablespaces --skip-triggers），但需人工清理 8.0 特有语法（如隐藏索引、角色语法、JSON_TABLE 等） - 所有抢救操作都必须在停机状态下进行，且不能有任何应用连接残留
回滚最常被忽略的一点：它不是升级的“备选动作”，而是升级前就必须验证通过的完整闭环。你手里的备份能不能真正在旧版上跑起来、权限对不对、字符集会不会隐式转换、连接池会不会因 plugin 不匹配拒绝认证——这些都得在测试环境里实打实走一遍，而不是等到生产出事才第一次执行。
