mysql 5.6 直升 8.0 必然失败，因架构断层：8.0 数据字典全 innodb 事务化，而 5.6 仍为 myisam 依赖 .frm 文件；5.7 是唯一官方验证的过渡层，承担系统表转换、格式校验与兼容层构建。
MySQL 5.6 → 8.0 跳过 5.7 必然启动失败
不是配置或操作问题，是架构断层导致的硬性失败。MySQL 8.0 的数据字典（mysql 库）已彻底重构为全 InnoDB 托管、事务化、只读结构，而 5.6 的 mysql 表仍是 MyISAM，且依赖 .frm 文件和分散元数据。中间缺失 5.7 就像拆掉承重墙后直接盖新楼——mysqld 启动时根本找不到迁移上下文，报错如 MY-010020 Data Dictionary initialization failed 或 Failed to open the data dictionary table mysql.user，此时删 mysql.ibd、清 datadir 都无效。
5.7 是唯一被官方验证的兼容过渡层
5.7 不是“可选中间件”，而是 8.0 升级路径中不可替代的翻译器：
- 它把 5.6 的
MyISAM系统表批量转为InnoDB（如mysql.plugin、mysql.proc），并引入字典兼容层 - 它首次启用
innodb_file_format = Barracuda和innodb_large_prefix校验，提前暴露 5.6 数据文件格式问题 - 它开始废弃旧 SQL mode（如
NO_AUTO_CREATE_USER），但仅警告；8.0 直接拒绝含该 mode 的配置启动 - 它支持
--upgrade=FORCE并能安全重建系统表结构，而 8.0 已移除mysql_upgrade，改由启动参数--upgrade=FORCE触发自动迁移
跳过中间版本后残留的三类元数据“毛刺”
即使强行用 dump/reload 绕过就地升级，5.6 遗留的元数据结构仍会卡住 8.0：
-
MyISAM系统表残留：运行SELECT table_schema, table_name, engine FROM information_schema.tables WHERE table_schema = 'mysql' AND engine = 'MyISAM';，对结果中的每张表执行ALTER TABLE mysql.plugin ENGINE=InnoDB; - 非法分区表：查出
create_options LIKE '%partitioned%' AND engine != 'InnoDB'的表，必须先转引擎再确认分区属性 - 孤立
.frm/.ibd文件：在datadir下搜索*#sql-*.ibd和无对应表名的.frm，这些是 5.6 中断 DDL 留下的“幽灵文件”，停库后必须手动删除
真正麻烦的是每个环节都依赖前序环节的干净收尾
5.6 → 5.7 升级不干净，5.7 → 8.0 就注定失败。比如：
- 5.6 升级时没设
innodb_fast_shutdown=0，缓冲区未刷盘，5.7 启动可能因页损坏拒绝加载表空间 - 5.7 没清理
NO_ZERO_DATE，8.0 启动时直接拒绝加载旧表定义 - 5.7 没显式设
default_authentication_plugin=mysql_native_password，8.0 导入后用户默认变caching_sha2_password，应用连接报Authentication plugin 'caching_sha2_password' cannot be loaded
跨大版本升级不是换二进制那么简单，是逐层解构旧契约、重建新契约的过程。漏掉任意一层，后续所有操作都在错误基座上运行——表面启动成功，实则元数据已静默损坏。
