MySQL升级失败后不可直接卸载降级，唯一可靠回滚是用升级前合规逻辑备份（含--single-transaction --routines --triggers --events且排除sys/performance_schema）导入旧版实例；物理备份仅限同大版本内小版本回退，且需匹配认证插件配置。
mysqld启动失败时先确认错误日志里报什么
别急着删文件或重装，先看错误日志定位根本原因。常见报错包括：Table 'mysql.user' doesn't exist、InnoDB: Unsupported redo log format、Data Dictionary initialization failed。这些不是配置写错了，而是新版本已改写底层结构——比如 MySQL 8.0+ 的 caching_sha2_password 插件、InnoDB redo log 格式、系统表字段定义，旧版 mysqld 压根不认识。
用 mysqldump 备份恢复必须满足三个硬条件
不是随便一个 mysqldump --all-databases 就能救回来。缺一不可：
- 导出命令必须带
--single-transaction --routines --triggers --events，否则存储过程、事件、触发器全丢 - 必须排除
sys和performance_schema库，它们在不同版本间不兼容，强行导入会卡住或报错 - 导入目标必须是旧版本 mysqld 实例，且
default_authentication_plugin配置要匹配（例如 5.7 是mysql_native_password，8.0+ 默认是caching_sha2_password）
物理备份（XtraBackup）回滚快但版本锁死风险高
如果你用了 Percona XtraBackup，恢复速度远超逻辑导入，但只适用于「同大版本内小版本升级」场景。比如从 8.0.32 升到 8.0.42 失败，用备份直接还原即可；但若从 5.7 升到 8.0 后失败，XtraBackup 备份无法被 5.7 启动——InnoDB 表空间格式已升级，旧版读不了。
实操要点：
- 停止当前 mysqld，确保无写入
- 清空目标 datadir（如
/var/lib/mysql），再用xtrabackup --copy-back还原 - 还原后执行
chown -R mysql:mysql /var/lib/mysql，权限不对会导致启动失败
恢复后登录失败大概率是认证插件不匹配
即使数据恢复成功，mysql -u root -p 连不上，八成是密码哈希方式变了。MySQL 8.0+ 默认用 caching_sha2_password，而 5.7 只认 mysql_native_password。解决方法不是重设密码，而是改配置：
- 在旧版
my.cnf的[mysqld]段落加一行：default_authentication_plugin=mysql_native_password - 重启 mysqld，再用原密码登录
- 如果仍不行，临时启
skip-grant-tables，进库执行：ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'yourpwd';
真正麻烦的不是操作步骤多，而是备份那一刻没留心 --routines 和 --ignore-table 参数——等报错才发现，已经晚了。
