MySQL 9.x 目前不存在，官方最新稳定版是8.4.4；所谓“9.x”多为云厂商自研版、第三方分支或误标；确认是否官方版需执行mysql -V查看输出；升级至8.4.4须满足旧版≥8.0.11且严格遵循配置、字符集、备份等要求。
MySQL 9.x 目前不存在——截至 2026 年 8 月，MySQL 官方最新稳定版本是 8.4.4（2026 年 6 月发布），没有 MySQL 9.x 版本。如果你看到所谓“MySQL 9.x 创新版”，极大概率是以下三种情况之一：
- 某些云厂商（如阿里云、腾讯云）基于 MySQL 8.x 自研的增强版，打上了内部代号“9.x”；
- 第三方 fork（如 Percona Server、MariaDB）的非官方命名；
- 错误信息、测试分支名或营销话术（例如把 MySQL 8.4 的某个 preview build 误标为 9.0）。
所以，“升级到最新版本”的前提，是先确认你当前用的到底是不是官方 MySQL。
怎么确认你装的是不是官方 MySQL？
执行这条命令：
mysql -V
输出类似 mysql Ver 8.0.33 for Linux on x86_64 (MySQL Community Server - GPL) 才是官方版；如果显示 Percona Server、MariaDB 或带厂商前缀（如 AliSQL、TDSQL），那就不是标准 MySQL，升级路径完全不同。
如果你确认用的是官方 MySQL 8.x，如何升到最新 8.4.x？
官方只支持同一大版本内小版本升级（如 8.0.33 → 8.4.4），且必须满足：旧版 ≥ 8.0.11（否则无法直接跳转）。操作本身不复杂，但容易翻车的点很具体：
- 不用
mysql_upgrade：它在 8.0.16+ 已废弃，启动时自动触发系统表升级，强行运行会报错 - 不能跳过配置检查：8.4 默认启用
require_row_format，若旧库有 MyISAM 表或无显式 ROW_FORMAT 的 InnoDB 表，启动会失败 - 字符集要显式设为
utf8mb4：8.4 默认collation_server是utf8mb4_0900_as_cs，老配置里写utf8会导致启动拒绝加载 - 备份必须含权限导出：用
mysqldump -u root -p --all-databases --routines --triggers --events --skip-lock-tables，单靠--all-databases不会导出mysql.user权限
升级后必查的三个地方
服务起来不代表升级成功。以下检查缺一不可：
- 运行
SELECT @@version, @@default_authentication_plugin;—— 确认版本是8.4.4且插件是caching_sha2_password（除非你手动改回mysql_native_password） - 查错误日志：
tail -n 50 /var/log/mysql/error.log，重点看有没有InnoDB: Unsupported redo log format或Failed to initialize DD - 连一次旧应用：某些 ORM（如 Django 4.2+）默认不兼容
caching_sha2_password，连接字符串得加?auth_plugin=mysql_native_password
真正麻烦的从来不是换二进制文件，而是旧 SQL 模式（比如 ONLY_FULL_GROUP_BY 在 8.4 中更严格）、函数弃用（UNIX_TIMESTAMP(NOW()) 被警告）、甚至客户端驱动版本太低连不上。别信“一键升级”，每一步背后都有隐性依赖。
