mysql 8.0无法降级至5.7，因数据字典、innodb redo log v5格式、系统表结构等底层变更不可逆，导致5.7 mysqld启动即报unsupported redo log format或table 'mysql.component' doesn't exist等硬性错误。
MySQL 8.0 启动后无法回退到 5.7 的根本原因
不是配置没改对，也不是权限没给足，而是数据字典、InnoDB redo log 格式、系统表结构这些底层文件已被 8.0 永久改写，5.7 的 mysqld 进程压根不认识——启动直接报错，连初始化都过不去。
典型现象包括：InnoDB: Unsupported redo log format、Table 'mysql.component' doesn't exist、Unknown table engine 'InnoDB'。这些不是警告，是硬性拒绝，说明磁盘上已有不可逆变更。
-
ib_logfile*被 8.0 写过一次，格式升为 v5，5.7 解析失败即卡死 -
mysql.user表从 42 列扩到 49 列（如新增password_reuse_history），5.7 读取时跳表或崩溃 - 8.0 默认启用
caching_sha2_password插件，而 5.7 根本不识别该值，若配置里留着default_authentication_plugin=caching_sha2_password，5.7 启动直接退出
为什么直接复制 datadir 或用 XtraBackup 恢复也失败
物理文件看似完整，但元数据层面已“中毒”。哪怕没执行 mysql_upgrade，只要 8.0 的 mysqld 进程打开过 ibdata1，InnoDB 就可能静默升级表空间头编码或 redo log 格式。
常见陷阱：
- 8.0 创建的通用表空间（
CREATE TABLESPACE ... ADD DATAFILE）在 5.7 下无法识别，SHOW CREATE TABLE直接报Table doesn't exist - 8.0 使用
COMPRESSED行格式的表，在 5.6/5.7 完全不支持，首次读取就crash -
innodb_file_format=Barracuda在 5.6 存在，但 8.0 的压缩页结构与之不兼容，启动后查表即崩
mysqldump 导出后导入 5.7 仍失败的常见坑
逻辑备份是唯一可行路径，但漏一个参数或少一步替换，导入就会中断。重点不是“导出来”，而是“导得兼容”。
- 必须加
--routines --events --triggers --single-transaction，否则存储过程、事件、触发器元数据全空 - 必须显式排除
--ignore-table=sys.sys_config --ignore-table=performance_schema.*，这两库在 5.7/8.0 间结构不兼容 - 导出 SQL 中所有
utf8mb4_0900_ai_ci要手动替换成utf8mb4_general_ci，否则建表失败 - 含
IDENTIFIED WITH caching_sha2_password的CREATE USER语句要删掉或重写为SET PASSWORD FOR 'u'@'h' = PASSWORD('p')
真正能用的回滚动作只依赖三件事
回滚不是“恢复备份”就完事，而是整套环境重建。能否成功，只取决于升级前是否做完以下三件事：
- 用
mysqldump导出时加了--set-gtid-purged=OFF --no-tablespaces --skip-extended-insert --column-statistics=0 - 旧版实例的
datadir是空的，且配置文件中没有残留default_authentication_plugin=caching_sha2_password - 手动清理了导出 SQL 中所有 8.0 特有语法，并统一了字符集排序规则
最常被忽略的是：权限体系不能靠 GRANT 语句简单还原，mysql.user 表结构变了，字段长度和哈希方式都不同，连 SELECT USER() 都可能崩溃。
