mysql 9.7.0 lts 不支持从 5.7 直接升级，必须经 8.0 和 8.4 中间版本，因数据字典、权限模型、认证插件及系统表结构完全不兼容，官方校验会拒绝启动旧格式 mysql 系统库。
MySQL 9.x（目前指 9.7.0 LTS）不接受任何来自 5.7 的直接升级，也不支持跳过 8.0 或 8.4 的中间版本。官方只承认一条路径：5.7 → 8.0 → 8.4 → 9.7.0 LTS。
为什么不能从 5.7 直接升到 9.7.0 LTS
MySQL 9.x 的数据字典、权限模型、JSON 处理逻辑、默认认证插件（caching_sha2_password）、事务日志格式等底层结构已与 5.7 完全不兼容。强行 in-place 升级会导致 mysqld 启动失败、系统表损坏、甚至数据不可读。官方明确禁用该操作，并在 9.7.0 的安装脚本中加入校验：若检测到 mysql 系统库仍为 5.7 格式，会直接拒绝启动。
- 5.7 的
mysql.user表结构无法被 9.x 解析，必须经由 8.0 的mysql_upgrade（或其替代机制）转换为字典表格式 - 5.7 默认的
sql_mode（如缺失STRICT_TRANS_TABLES）在 9.x 中会被强制重置，但未经过 8.0 中间层校验时，表定义可能残留不合法字段类型 - 所有存储过程、函数、触发器的元数据在 5.7→9.x 过程中无对应迁移逻辑，会丢失或报错
ERROR 1449 (HY000): The user specified as a definer does not exist
8.0 和 8.4 是绕不开的必经中间版本
8.0 是语义和结构上的分水岭，8.4 是首个正式 LTS 版本，二者共同承担“翻译层”角色：8.0 完成数据字典重构、认证插件切换、SQL_MODE 收紧；8.4 则完成 JSON 索引优化、并行复制协议升级、以及为 9.x 铺设的元数据压缩格式。
- 从 5.7 升到 8.0 后，必须运行
mysqld --upgrade=FORCE（而非已废弃的mysql_upgrade），否则information_schema视图将无法反映新结构 - 8.0 → 8.4 升级虽属小版本跃迁，但需确认是否启用了
innodb_parallel_read_threads等新参数——这些参数在 8.4 中默认开启，若 8.0 未启用，升级后可能引发查询计划突变 - 8.4 → 9.7.0 LTS 不再需要手动执行升级命令，但必须确保
default_authentication_plugin已设为caching_sha2_password，否则 9.x 初始化阶段会拒绝加载用户账户
升级失败最常卡在哪儿
不是二进制替换失败，而是元数据校验通不过。9.7.0 启动时会扫描所有数据库下的 INFORMATION_SCHEMA 兼容性标记，只要发现任意一张表仍带 5.7 风格的 CREATE_TIME 或 UPDATE_TIME 字段（非虚拟列），就会终止启动并输出错误：Server initialization failed: Incompatible system table structure detected in mysql.innodb_table_stats。
- 常见诱因：升级中途中断后未清空
mysql.ibd，残留旧版系统表空间 - 误删了 8.0 升级后生成的
mysql.ibdata1，导致 9.x 无法重建字典缓存 - 使用
mysqldump --all-databases --no-create-info导出再导入，漏掉了mysql库中 8.0 新增的role_edges、password_history等表
真正麻烦的不是步骤多，而是每个中间版本都必须完整跑通元数据升级流程，且不能跳过验证环节——哪怕只是改了一行 my.cnf，重启后也得确认 SELECT @@version 和 SHOW VARIABLES LIKE 'default_authentication_plugin' 是否符合预期。漏掉一次检查，问题会累积到 9.x 才爆发，那时回滚代价就远不止停机两小时了。
