mysql 8.4 升级到 9.x 不推荐且不可行，因 mysql 9.x 尚未发布 ga 版本，官方仅提供预览版或实验分支；合法升级路径为 8.4 → 下一 lts 版本（预计 10.0，2028 年发布）。
MySQL 8.4 升级到 9.x（如 9.0 或 9.1）目前**不推荐、不可行，且官方不支持**。这不是配置或操作问题，而是版本策略和工程现实决定的。
MySQL 9.x 尚未发布正式 LTS 版本
截至 2026 年 8 月，MySQL 官方**没有发布任何 9.x 的 GA（General Availability）版本**。所谓 “MySQL 9.0” 仅存在于预览版（Preview Release）或内部测试分支中，Oracle 官方文档、下载页面、Release Notes 均未将其列为支持版本。你看到的 “9.0” 多数来自非官方渠道误传、第三方包装、或对 MySQL 9.6.0（Linux 创新版）的混淆——后者是 2026 年推出的 innovation 分支实验版本，不是生产可用的 GA 版本。
这意味着：
-
mysqld --version不会返回9.0.x； -
mysql --version也不会显示 9.x； - 所有主流包管理器（apt/yum/dnf）、Docker Hub 官方镜像、云厂商 RDS 控制台均不提供 9.x 安装源；
-
mysql_upgrade或mysqld --initialize在 9.x 下无法通过基础校验。
升级路径只允许跨一个主版本，且必须是 GA 版本
MySQL 官方明确要求：升级必须严格遵循相邻 GA 主版本路径，且目标版本需在 Supported Platforms 列表中。当前合法路径只有：
- 8.0 → 8.1 → 8.2 → 8.3 → 8.4（LTS）
- 8.4 → 下一个 LTS（预计为 10.0，2028 年发布）
跳过 8.4 直接尝试“升级”到 9.x 会导致：
-
mysqld启动失败，报错Table 'mysql.component' doesn't exist或Unknown system variable 'innodb_redo_log_capacity'； - 数据字典初始化中断，
mysql.system_versioning等核心系统表缺失； - 二进制日志格式不兼容，主从复制直接断裂；
- Percona Toolkit、pt-upgrade、mysqldump 等工具拒绝连接或解析失败。
如果你真看到“MySQL 9.x”在跑，大概率是容器镜像或自编译陷阱
某些 Dockerfile 或 CI 脚本会拉取 mysql:latest 或 mysql:9 标签，但这些标签实际指向的是开发分支快照（如 mysql:9.6.0），并非 GA 版本。它可能：
- 缺少完整 SQL 函数实现（如
JSON_SCHEMA_VALIDATE()返回空或 panic）； - 不兼容标准 JDBC/Connector/J 驱动，连接时抛出
Unknown authentication plugin: caching_sha2_password； - 无法执行
SHOW VARIABLES LIKE 'version%'—— 因为version变量本身未注册； - 触发器、存储过程在
CREATE PROCEDURE解析阶段直接报错ERROR 1064 (42000)。
这种环境连基本的 SELECT 1 都可能不稳定，更不用说评估兼容性。
真正需要升级的场景，现在只有一条路：确认你已在 8.4 LTS（支持至 2032 年），然后盯紧 Oracle 官网公告——下一个正式支持的主版本只会是 10.0，而非 9.x。任何声称“已上线 MySQL 9”的方案，背后要么是包装版、要么是测试陷阱，上线即踩坑。
