MySQL 8.0升级失败后不可直接卸载重装旧版，因数据字典、redo log格式、authentication_string加密方式及default_authentication_plugin已被改写，强行降级将触发InnoDB: Unsupported redo log format或Table 'mysql.component' doesn't exist等错误导致实例无法启动。
MySQL 8.0升级失败后，不能卸载新版本、重装旧版二进制再启动——99% 的回滚失败都卡在这一步。底层数据字典、innodb_redo_log_format、authentication_string 加密方式和 default_authentication_plugin 已被改写，旧版 mysqld 启动即报 InnoDB: Unsupported redo log format 或 Table 'mysql.component' doesn't exist，实例根本起不来。
确认是否还能走“原地降级”路径
官方仅对极少数场景允许不还原数据的快速降级，必须同时满足全部条件：
- 是同一 major 版本内相邻小版本（如
8.0.34 → 8.0.33） - 升级后从未真正启动过新实例，或仅以
--upgrade=NONE模式做过只读检查 - 未执行过
mysql_upgrade或等效的mysqld --upgrade=FORCE - 未写入任何数据（包括
INSERT/UPDATE/DDL），binlog和redo log仍是升级前状态
只要其中任一条件不满足，立刻放弃覆盖安装，切到备份恢复流程。
用逻辑备份（mysqldump）最快恢复业务
这是生产环境最可控、兼容性最强的回滚方式，但前提是升级前执行过合规导出：
- 导出命令必须含
--single-transaction --routines --events --triggers --set-gtid-purged=OFF，否则存储过程、事件、触发器全丢 - 务必排除
sys和performance_schema库：--ignore-table=sys.% --ignore-table=performance_schema.%，二者在 5.7/8.0 间结构不兼容 - 导入目标必须是旧版本
mysqld实例，且配置中default_authentication_plugin匹配（如 MySQL 5.7 要设为mysql_native_password） - 导入时加
--default-character-set=utf8mb4，避免字符集隐式转换导致乱码；若导出含utf8mb4_0900_ai_ci排序规则，需批量替换为utf8mb4_general_ci - 含
IDENTIFIED WITH caching_sha2_password的CREATE USER语句在 5.7 不识别，需手动删掉或重写为SET PASSWORD FOR 'u'@'h' = PASSWORD('p')
示例：在旧版 MySQL 启动空实例后执行
mysql -u root -p --default-character-set=utf8mb4 your_db < pre_upgrade.sql
物理备份（XtraBackup）恢复更快但版本锁死严格
适合大库（>100GB）、RTO 要求极严的场景，但风险点更隐蔽：
-
xtrabackup8.0.33 备份只能用 8.0.33 或更高小版本的xtrabackup恢复，不能倒灌给 8.0.32 - 恢复后首次启动若报
Tablespace not found，说明新版本已修改表空间元数据，此时必须加--innodb-force-recovery=1启动，再用mysqldump导出，最后导入干净旧实例 - 若报
LSN不匹配（如page log sequence number is in the future），说明ib_logfile*与数据文件不同步，不能简单删除日志，需先尝试--innodb-force-recovery，失败则必须走逻辑备份兜底
真正容易被忽略的是：哪怕你有 XtraBackup，只要没验证过恢复流程，它就不是“可用备份”。升级前必须在测试环境完整跑通一次 restore + start + select 流程，否则线上恢复时发现备份不可用，就只剩黄金 20 分钟止损窗口了。
