mysql 5.6→8.0 直接升级不可行，必须经5.7过渡；因数据字典架构断层，跳过5.7会导致mysqld启动卡死在data dictionary initialization failed，并引发gtid失效、系统表损坏及sql层崩溃。
MySQL 5.6 → 8.0 直接升级必然失败，不是“风险高”，而是“根本不可行”
官方明确不支持该路径，跳过 5.7 会导致 mysqld 启动卡死在 Data Dictionary initialization failed，日志中反复出现 MY-010020 或 MY-011014。这不是配置没调好、参数没设对的问题，是数据字典架构断层导致的底层崩溃。
- MySQL 5.6 的元数据分散存储：系统表（如
mysql.user）是 MyISAM 引擎，依赖.frm文件 + 内存结构 + InnoDB 内部字典页 - MySQL 8.0 强制使用集中式事务性字典：全部元数据必须存于
mysql.ibd，由 InnoDB 托管，且不可直写 - 中间缺失 5.7 的过渡层：5.7 已开始将系统表转为 InnoDB，并引入字典兼容逻辑；没有它，8.0 的
--upgrade=FORCE根本无法识别 5.6 的旧格式，也无法生成合法字典结构
即使手动删掉 mysql.ibd 或清空 data 目录重试，残留的 #sql-*.ibd 临时文件或损坏的 ibdata1 页面仍会触发 Got error 197 from SE，后续启动直接拒绝。
GTID 复制状态丢失后无法恢复
5.6 启用 GTID 时，复制位点信息存在 mysql.gtid_executed 表（MyISAM），而 8.0 要求该表为 InnoDB 且结构完全重定义。跳过 5.7 意味着：
-
SELECT @@gtid_executed返回空或乱码 - 主从同步中断后，
CHANGE MASTER TO ... GTID_SET无法正确解析起点 - 即便强行跳过，后续 binlog event 解析错位，造成主从数据永久不一致
这不是“可能出问题”，而是 GTID 复制链在首次启动时就已断裂，且无补救手段。
系统表损坏后连基础查询都失败
常见现象包括：
- 启动后执行
SHOW DATABASES报错Unknown table engine 'InnoDB'（实为引擎识别逻辑错乱） -
SELECT * FROM mysql.user提示Failed to open the data dictionary table mysql.user -
mysql_upgrade在 8.0 中已被移除，但有人误在 5.6 数据目录下用 8.0 客户端运行它，结果提示Command not found并静默失败
这些都不是应用层兼容性问题，是字典初始化失败后，整个 SQL 层失去元数据支撑的表现。此时数据库已无法进入可用状态，只能回退或重建。
字符集与 SQL mode 错位会掩盖真正故障点
很多人看到 Client does not support authentication protocol requested by server 或 Expression #1 of SELECT list is not in GROUP BY clause 就以为是配置或 SQL 问题，急着改 default_authentication_plugin 或降级 sql_mode。但真实情况是：
- 这些报错往往出现在字典勉强加载成功但部分系统表未修复的“半残废”状态
- 真正根源仍是 5.6→8.0 跳步导致的
mysql.plugin、mysql.proc等表引擎未转 InnoDB、结构未升级 - 修了表名大小写或认证插件，下次重启照样卡在
MY-010020
最易被忽略的是：哪怕你把所有用户表都转成了 utf8mb4 和 InnoDB，只要 mysql 库本身没经过 5.7 的迁移上下文，8.0 就永远无法完成字典初始化——这是不可绕过的原子步骤。
