回滚失败的mysql升级唯一可靠方式是用旧版mysqld启动升级前的合规备份；官方仅支持相邻小版本有限降级，且须满足新版本未写入数据、未执行mysql_upgrade两个硬性条件，否则覆盖降级不可行。
回滚失败的 MySQL 版本升级，没有“一键倒退”选项；唯一可靠路径是用旧版 mysqld 启动升级前备份的干净副本——前提是备份存在、类型合规、且未被覆盖。
确认是否还能走“覆盖降级”这条路
官方只对相邻小版本（如 8.0.33 → 8.0.32）提供有限降级支持，且必须同时满足两个硬性条件：新版本 mysqld 从未正常启动写入过数据；且没执行过 mysql_upgrade 或等效的 mysqld --upgrade=FORCE。一旦出现 ERROR 1932 (HY000)、Table 'mysql.user' doesn't exist 或日志里有 InnoDB: Unsupported redo log format，说明 InnoDB 日志或系统表结构已被改写，覆盖降级已不可行。
- 检查进程：运行
ps aux | grep mysqld，确认新版本进程是否曾以读写模式运行过 - 查日志：翻
/var/log/mysqld.log，搜索Upgrade completed或Upgrading system tables字样 - 别碰
datadir：如果迁移脚本执行了rsync --delete或cp -r，原数据很可能已不可逆丢失
用 mysqldump 回滚：适用小规模实例（≤5GB）
这是生产中最常落地的方案，但要求备份命令含关键参数，否则导入后会丢触发器、事件、存储过程，甚至连不上 mysql 库。
- 导出时必须带：
--single-transaction --routines --events --triggers - 不能用
--all-databases直接导，要排除不兼容库：--ignore-table=sys.sys_config --ignore-table=performance_schema.* - 导入目标必须是旧版
mysqld实例，且配置中default_authentication_plugin要匹配（例如 5.7 是mysql_native_password，8.0+ 默认是caching_sha2_password） - 导入前先关外键检查：
mysql -u root -e "SET FOREIGN_KEY_CHECKS=0;"，再执行mysql -u root - 若备份不含
mysql库，需手动重建用户：用旧版mysql_upgrade（5.7）或从mysql_system_tables.sql初始化，否则报Access denied for user
用 XtraBackup 物理回滚：快但版本锁死严重
物理备份恢复速度远超逻辑导入，但不是“解压即用”。XtraBackup 8.0 备份只能由同主版本的 XtraBackup 恢复，且恢复后首次启动会被旧版 mysqld 拒绝加载——因表空间已被新版本标记为“不可降级”。
- 恢复命令必须用对应旧版工具：
xtrabackup --copy-back --target-dir=/path/to/backup - 启动时加
--innodb-force-recovery=1绕过校验，再用mysqldump导出全量逻辑数据 - 绝对不要手动拷贝
ibdata1或ib_logfile*到旧版datadir——redo log 格式已变更，必然报错 - 若备份是 XtraBackup 8.0.33，不能给 8.0.32 用；跨小版本需确保 y ≥ x（即恢复版本 ≥ 备份版本）
没备份？优先抢救，别碰数据目录
升级失败但尚未写入业务数据时，还有微弱抢救机会；一旦执行过任何 INSERT 或 mysql_upgrade，就彻底放弃“覆盖降级”幻想。
- 若卡在启动阶段，错误日志出现
Unknown table 'mysql.component'，可尝试用升级前备份的整个mysql子目录覆盖当前datadir/mysql/（仅此库） - 若看到
MY-010020 Data Dictionary initialization failed，说明是 5.6→8.0 直升失败，必须经由 5.7 中转，不能硬上 - 登录后权限异常？执行
SELECT User, Host, plugin FROM mysql.user，若插件是caching_sha2_password但客户端不支持，临时切回：ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'xxx'; FLUSH PRIVILEGES; - 别删
ib_logfile*或清空datadir——这只会让 InnoDB 启动更失败
真正决定回滚成败的，从来不是操作步骤，而是升级前有没有保留一份可用、一致、可验证的备份，并且知道它能还原什么、不能还原什么。最容易被忽略的是 default_authentication_plugin 和 mysql 系统库的完整性——这两点一错，连得进也干不了事。
