mysql 8.0升级失败主因是数据字典与5.7元数据硬性不兼容，需通过mysqlcheck --check-upgrade预检、强制转系统表为innodb、统一utf8mb4_0900_ai_ci排序规则及修复lsn一致性来解决。
升级失败常卡在元数据层面，不是配置写错，而是 MySQL 8.0 的数据字典（Data Dictionary）与 5.7 留下的元数据结构存在硬性不兼容——跳过检查直接启动，mysqld 会拒绝加载并报错退出。
mysqlcheck --check-upgrade 必须跑，且不能只看“成功”
很多 DBA 运行 mysqlcheck -u root -p --all-databases --check-upgrade 后看到“OK”就以为过关，其实它只报告显式不兼容项。真正危险的是隐性冲突：
-
--check-upgrade不检测mysql系统库中用户自建的同名表（如columns、events），但 8.0 启动时会因表名冲突直接 abort - 它不校验
information_schema视图背后的真实元数据一致性，比如INNODB_SYS_TABLES中存在记录，但TABLES表里查不到对应行 - 遇到
ERROR: The table does not comply with the current version of MySQL，说明该表含 5.7 特有语法（如ENUM默认值为空字符串），必须用ALTER TABLE ... FORCE或CREATE TABLE AS SELECT重建
系统表引擎残留：MyISAM → InnoDB 强制转换失败
MySQL 8.0 彻底移除 MyISAM 对系统表的支持。若 5.7 的 mysql.plugin 或 mysql.servers 仍是 MyISAM 引擎，mysqld --upgrade=FORCE 会报 Can't find file: './mysql/plugin.frm' 并中断。
- 先确认：执行
SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='mysql' AND TABLE_NAME IN ('plugin','servers'); - 若返回
MyISAM，不能等升级命令自动修复——需在 5.7 环境下手动转引擎：ALTER TABLE mysql.plugin ENGINE=InnoDB;（注意：操作前必须停写、设innodb_fast_shutdown=0） - 转完后立即执行
mysqlcheck --repair --use-frm mysql plugin，确保 frm 文件与 ibd 同步
字符集与排序规则混用导致启动阶段崩溃
升级后首次启动报 Illegal mix of collations 或直接 abort，大概率是 mysql 系统库或用户库的默认 COLLATE 混合了 utf8mb4_general_ci 和 utf8mb4_0900_ai_ci。
- 8.0 要求整个数据字典统一使用
utf8mb4_0900_ai_ci，但 5.7 备份或迁移脚本中可能带入旧 collation 声明 - 检查关键位置：
SELECT SCHEMA_NAME, DEFAULT_COLLATION_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME IN ('mysql', 'information_schema'); - 若
mysql库返回utf8mb4_general_ci，不能用ALTER DATABASE修改——系统库不允许直接改，默认 collation 由初始化参数决定。必须重跑mysqld --initialize初始化新系统库，再导入用户数据 - 用户库可安全修改：
ALTER DATABASE your_db CHARACTER SET = utf8mb4 COLLATE = utf8mb4_0900_ai_ci;，但需配合所有表级 collation 同步更新
LSN 不一致引发数据字典初始化失败
错误日志出现 Tablespace 'mysql' log sequence number is in the future!，说明 InnoDB redo 日志与数据页 LSN 错位——这不是 SQL 层问题，而是物理文件状态异常。
- 该问题多发生在非干净关闭的 5.7 实例上（如 kill -9、断电），导致
ib_logfile*未刷全 - 不要删
ib_logfile*后硬启：8.0 会尝试恢复，但 LSN 跳变可能触发断言失败（如log0buf.cc:883:start_sn > 0） - 正确做法：回到 5.7 环境，设
innodb_force_recovery=1启动，执行FLUSH TABLES WITH READ LOCK; SET GLOBAL innodb_fast_shutdown=0;，再正常关闭，此时 redo 日志才完整 - 升级前务必验证：运行
mysqld --validate-config --datadir=/var/lib/mysql（8.0.23+ 支持），它会提前暴露 LSN/目录权限类底层问题
元数据冲突的本质是 5.7 和 8.0 对“数据库是什么”的定义发生了根本变化——不是字段少个逗号就能修好，而是得让旧结构主动适配新契约。最容易被忽略的是：那些没报错、没警告、但悄悄留在 mysql 库里的自定义表，它们会在 8.0 启动瞬间变成定时炸弹。
