必须经MySQL 5.7中转升级：官方仅支持5.6→5.7→8.0线性路径，因8.0彻底重构数据字典架构，跳过5.7会导致字典初始化失败、系统表损坏、GTID复制中断及mysqld启动失败。
不能直接从 MySQL 5.6 升级到 8.0，跳过 5.7 会导致数据字典初始化失败、系统表损坏、GTID 复制中断，甚至 mysqld 启动直接报错 MY-010020 或 MY-011014 —— 这不是配置问题，是架构断层，无绕过方案。
为什么跳过 5.7 必然失败
MySQL 8.0 彻底重构了数据字典（Data Dictionary）：5.6/5.7 使用分散式元数据（mysql 库表 + .frm 文件 + InnoDB 内部结构），而 8.0 强制使用集中式、事务性、InnoDB 托管的字典（全部存于 mysql.ibd）。跳过 5.7 意味着缺失中间迁移上下文，mysqld --upgrade 无法识别 5.6 的旧格式，也无法生成 8.0 所需的原子化字典表。
-
mysqld启动时卡在 “Data Dictionary initialization failed”，日志里反复出现MY-010020 - 即使手动删掉
mysql.ibd或清空data目录重试，残留的#sql-*.ibd临时文件或损坏的ibdata1页面结构仍会触发Got error 197 from SE - GTID 复制状态丢失，
SELECT @@gtid_executed返回空或乱码，后续主从同步完全不可靠
必须走 5.6 → 5.7 → 8.0 两步路径
这是唯一被 MySQL 官方验证、能规避元数据损坏的路径。每一步都不可省略，且需满足具体条件：
- 第一步：将 5.6 升级至最新 5.7.x（如
5.7.35），启动后必须成功执行mysql_upgrade --force - 确认所有
mysql系统表已转为 InnoDB 引擎：运行SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'mysql' AND engine != 'InnoDB';，对结果中每张表（如plugin、proc）执行ALTER TABLE mysql.plugin ENGINE=InnoDB; - 第二步：用 MySQL 8.0 二进制替换 5.7，首次启动时加
--upgrade=FORCE，此时字典迁移才有完整中间态可依赖
5.6 遗留的三类元数据“毛刺”必须清理
即便走完两步路径，5.6 时期遗留的结构不一致仍会卡住 8.0 启动。必须停库后人工检查并处理：
- MyISAM 系统表残留：
SELECT table_schema, table_name, engine FROM information_schema.tables WHERE table_schema = 'mysql' AND engine = 'MyISAM';—— 对每张结果表执行ALTER TABLE ... ENGINE=InnoDB; - 非法分区表引擎：
SELECT table_schema, table_name FROM information_schema.tables WHERE create_options LIKE '%partitioned%' AND engine != 'InnoDB';—— 先转引擎，再确认分区定义是否兼容 8.0 - 孤立的
.frm/.ibd文件：在datadir下搜索*#sql-*.ibd和无对应表名的.frm，这些是 5.6 DDL 中断产生的“幽灵文件”，必须手动删除
升级后立即验证的元数据关键点
8.0 启动成功 ≠ 元数据就绪。以下检查项必须逐项通过，否则后续 DDL 或备份可能静默失败：
- 执行
SELECT * FROM mysql.innodb_table_stats;—— 若返回空或报错，说明统计信息未加载，ANALYZE TABLE会失效 - 检查
information_schema.INNODB_TABLESPACES是否可查，字段file_format应为Barracuda，row_format不应为Redundant - 运行
mysqlcheck --all-databases --check-upgrade，确认无error或warning级别输出
最容易被忽略的是：即使所有命令都跑通，mysql.ibd 文件内部的 page 结构若残留 5.6 时期的非事务性写入痕迹，会在第一次执行 CREATE TABLE ... PARTITION 时突然崩溃 —— 这种问题不会在启动阶段暴露，只在业务真实触发 DDL 时爆发。
