必须经5.6→5.7→8.0两步升级：因8.0彻底重构为innodb托管的事务性数据字典，跳过5.7会导致字典初始化失败（my-010020）、系统表损坏、gtid复制中断及mysqld启动失败。
mysql库表 + .frm 文件 + InnoDB 内部结构），而 8.0 强制使用集中式、事务性、InnoDB 托管的数据字典（全部存于 mysql.ibd）。跳过 5.7 会导致 mysqld 启动时直接报错 MY-010020 或 MY-011014，卡在 “Data Dictionary initialization failed”，且无法通过删 mysql.ibd 或清空 data 目录修复。
为什么 mysql_upgrade 在 5.6→8.0 路径下完全无效
mysql_upgrade 是为相邻版本设计的过渡工具，它依赖中间版本（5.7）提供的兼容层来识别并转换旧格式。5.6 的 mysql 系统表仍是 MyISAM，字段如 password 未被 authentication_string 替代，plugin 表结构也完全不同。直接在 8.0 上运行会提示 Command not found（8.0.16+ 已移除），或在 5.6 数据目录上强行调用则根本无法解析元数据。
宝塔面板的“升级”按钮是否支持 5.6→8.0 一步到位
不支持。宝塔 7.9+ 的 MySQL 升级功能仅封装官方原地升级流程，但该流程本身要求前置版本 ≥ 5.7.26。若当前是 5.6，点击“升级到 8.0”会失败并报错 Upgrade is not supported for this version。它不会自动帮你先升 5.7——这步必须人工完成，且需确认 innodb_fast_shutdown=0、无 skip-grant-tables、my.cnf 中无废弃 sql_mode（如 NO_AUTO_CREATE_USER）等四点前提。
如果硬要逻辑迁移，dump.sql 必须手动清理哪几类语句
仅当无法原地升级（如换服务器、换操作系统）时才考虑，且必须分三阶段人工干预：
- 导出时强制指定编码：
mysqldump --default-character-set=utf8mb4 -u root -p --single-transaction --routines --triggers --events --databases db1 db2 > dump.sql - 导入前清理
dump.sql：
• 删除所有对mysql库的CREATE DATABASE和INSERT INTO mysql.*语句
• 搜索替换ENGINE=MyISAM为ENGINE=InnoDB
• 删除含INNODB_前缀的用户表CREATE TABLE（避免与 8.0 系统视图冲突） - 导入后手动重建用户：
CREATE USER 'app'@'%' IDENTIFIED WITH caching_sha2_password BY 'pwd'; GRANT ...
5.6 → 5.7 → 8.0 路径，5.6 时期遗留的 ROW_FORMAT=COMPACT 表、未启用 innodb_file_per_table 的老数据文件、或残留的 #sql-*.ibd 临时文件，仍会在 8.0 首次启动时触发 Got error 197 from SE，必须停库后逐个检查并执行 ALTER TABLE t ROW_FORMAT=DYNAMIC; 和 SET GLOBAL innodb_file_per_table=ON;。
