MySQL 8.4升级MySQL 9.x前如何评估兼容性？

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 版本。

这意味着：

1. mysqld --version 不会返回 9.0.x；
2. mysql --version 也不会显示 9.x；
3. 所有主流包管理器（apt/yum/dnf）、Docker Hub 最新镜像、云厂商 RDS 控制台均不提供 9.x 安装源；
4. mysql_upgrade 或 mysqld --initialize 在 9.x 下无法通过基础校验。

升级路径只允许跨一个主版本，且必须是 GA 版本

MySQL 最新明确要求：升级必须严格遵循相邻 GA 主版本路径，且目标版本需在 Supported Platforms 列表中。当前合法路径只有：

1. 8.0 → 8.1 → 8.2 → 8.3 → 8.4（LTS）
2. 8.4 → 下一个 LTS（预计为 10.0，2028 年发布）

跳过 8.4 直接尝试“升级”到 9.x 会导致：

1. mysqld 启动失败，报错 Table 'mysql.component' doesn't exist 或 Unknown system variable 'innodb_redo_log_capacity'；
2. 数据字典初始化中断，mysql.system_versioning 等核心系统表缺失；
3. 二进制日志格式不兼容，主从复制直接断裂；
4. Percona Toolkit、pt-upgrade、mysqldump 等工具拒绝连接或解析失败。

如果你真看到“MySQL 9.x”在跑，大概率是容器镜像或自编译陷阱

某些 Dockerfile 或 CI 脚本会拉取 mysql:latest 或 mysql:9 标签，但这些标签实际指向的是开发分支快照（如 mysql:9.6.0），并非 GA 版本。它可能：

1. 缺少完整 SQL 函数实现（如 JSON_SCHEMA_VALIDATE() 返回空或 panic）；
2. 不兼容标准 JDBC/Connector/J 驱动，连接时抛出 Unknown authentication plugin: caching_sha2_password；
3. 无法执行 SHOW VARIABLES LIKE 'version%' —— 因为 version 变量本身未注册；
4. 触发器、存储过程在 CREATE PROCEDURE 解析阶段直接报错 ERROR 1064 (42000)。

这种环境连基本的 SELECT 1 都可能不稳定，更不用说评估兼容性。

真正需要升级的场景，现在只有一条路：确认你已在 8.4 LTS（支持至 2032 年），然后盯紧 Oracle 正式公告——下一个正式支持的主版本只会是 10.0，而非 9.x。任何声称“已上线 MySQL 9”的方案，背后要么是包装版、要么是测试陷阱，上线即踩坑。