必须经mysql 5.7中转升级：官方仅支持5.6→5.7→8.0线性路径，因8.0彻底重构数据字典架构，跳过5.7会导致字典初始化失败、系统表损坏、gtid复制中断及mysqld启动失败。
为什么不能直接从 5.6 跳到 8.0 升级
MySQL 官方明确不支持跨大版本的原地升级（如 5.6 → 8.0），根本原因是数据字典（Data Dictionary）架构彻底重构：5.6 和 5.7 使用分散式元数据（mysql 库表 + frm 文件 + InnoDB 内部结构），而 8.0 强制统一为集中式、事务性、InnoDB 托管的字典（存于 mysql.ibd）。跳过 5.7 中间层会导致字典迁移脚本缺失上下文，启动时直接报 MY-010020 Data Dictionary initialization failed 或 MY-011014 Found partially upgraded DD —— 这不是配置问题，是架构断层。
必须走 5.6 → 5.7 → 8.0 的两步升级路径
这是唯一被 MySQL 官方验证、能规避元数据损坏的路径。跳过 5.7 会让 mysqld --upgrade 无法识别 5.6 的旧字典格式，也无法生成 8.0 所需的原子化字典表。
- 先将 5.6 升级至最新 5.7.x（如
5.7.35），确保执行mysql_upgrade --force成功，且所有系统表（mysql.plugin、mysql.servers等）已转为 InnoDB 引擎 - 再用 8.0 的二进制替换 5.7，启动时会自动触发二次升级流程，此时字典迁移有完整中间态可依赖
- 若跳过 5.7，即使手动删掉
mysql.ibd或清空data目录重试，仍会因残留#sql-*.ibd临时表或损坏的ibdata1page 结构导致Got error 197 from SE
升级中必须清理的三类元数据残留
即便走两步路径，5.6 遗留的元数据“毛刺”仍会卡住 8.0 启动。重点检查并处理：
-
MyISAM 系统表残留：运行
SELECT table_schema, table_name, engine FROM information_schema.tables WHERE table_schema = 'mysql' AND engine = 'MyISAM';，对结果中的每张表（如plugin、proc）执行ALTER TABLE mysql.plugin ENGINE=InnoDB; -
非法分区表引擎：8.0 不允许 MyISAM 分区表，查出后必须先转引擎再确认分区属性：
SELECT table_schema, table_name FROM information_schema.tables WHERE create_options LIKE '%partitioned%' AND engine != 'InnoDB'; -
孤立的
.frm/.ibd文件：在datadir下搜索*#sql-*.ibd和未对应表名的.frm，这些是 5.6 时期中断 DDL 留下的“幽灵文件”，必须手动删除（停库后操作）
升级后立即验证的元数据关键点
8.0 启动成功不等于元数据就绪。必须逐项确认以下状态，否则后续 DDL 或备份可能静默失败：
- 执行
SELECT * FROM mysql.innodb_table_stats;—— 若报错或为空，说明字典迁移未完成，需重新运行mysql_upgrade - 检查
INFORMATION_SCHEMA.INNODB_TABLESPACES是否可查，且space_type字段存在（5.7 新增，8.0 强依赖） - 运行
SHOW CREATE TABLE mysql.columns_priv;，确认表结构含authentication_string字段（而非旧版的password），这是认证插件切换成功的标志
最易被忽略的是：升级后首次执行 CREATE TABLE 或 ALTER TABLE 时，若遇到 Table 'mysql.column_statistics' doesn't exist，说明字典初始化不完整，必须回退到 5.7 重新跑 mysql_upgrade，再试 8.0。
