直接升级可行，但必须绕开mysql_native_password插件缺失、caching_sha2_password兼容性问题、系统表升级失败三类高频故障；升级前须硬性验证操作系统≥centos 7.9/ubuntu 18.04/debian 10、mysql 8.0≥8.0.37、xa recover返回空结果。
直接升级是可行的，但必须跳过“只换二进制、不检查兼容性”这个坑——MySQL 8.0 到 8.4 不是小版本更新，而是 LTS 轮换，mysql_native_password 插件默认禁用、GROUP BY 隐式排序彻底移除、系统表结构变更等行为会直接导致业务连不上或查询结果错乱。
先跑 util.checkForServerUpgrade() 扫描真实风险
别信“测试环境没报错就没事”。官方升级检查器能发现你根本想不到的问题，比如某张表名撞了 8.4 新增保留字、某个函数在 8.4 里已被标记为废弃、甚至 mysql.user 表里残留的旧认证插件配置。
- 装 MySQL Shell 8.4（不能用 8.0 的 shell），运行：
mysqlsh root@localhost:3306 -- util checkForServerUpgrade --target-version=8.4.0 --output-format=TEXT
- 重点盯输出里的
ERROR和WARNING行，尤其是涉及mysql系统库、存储过程、触发器、事件调度器的部分 - 如果报告
Found 0 errors, 0 warnings，说明基础结构层大概率过关；但业务 SQL 层仍需人工抽检，比如所有带GROUP BY却没写ORDER BY的语句
mysqldump 导出时必须加 --single-transaction 和 --routines
不加这两个参数，导出来的数据可能不一致，或者丢了存储过程——尤其当你的业务依赖定时事件或复杂函数时，漏掉 --events 或 --routines 就等于上线后功能直接消失。
-
--single-transaction是 InnoDB 表一致性保障，避免备份中途写入导致幻读；但对 MyISAM 表无效，这类表必须停写或改用物理备份 - 导出命令示例：
mysqldump -u root -p --all-databases --single-transaction --routines --triggers --events > full_backup_8.4.sql
- 导完立刻验证：打开 SQL 文件，搜
CREATE PROCEDURE和CREATE EVENT，确认数量和内容与原库SHOW PROCEDURE STATUS输出匹配
导入到 8.4 后连不上？大概率是 mysql_native_password 插件没加载
这是升级后最常卡住的第一步。8.4 默认不加载该插件，而 mysqldump 会把 8.0 用户的认证方式原样导出，导致用户记录还在，但插件没了，登录直接报 Error 1524 (HY000): Plugin 'mysql_native_password' is not loaded。
- 临时解法（仅用于验证）：启动 8.4 实例时加参数
--default-authentication-plugin=mysql_native_password，或在my.cnf里写[mysqld] default_authentication_plugin=mysql_native_password
- 长期解法：批量重置用户密码，强制切换到
caching_sha2_password：ALTER USER 'app_user'@'%' IDENTIFIED WITH caching_sha2_password BY 'newpass';
- 注意：JDBC 连接串要同步加上
&serverTimezone=UTC&allowPublicKeyRetrieval=true，否则驱动可能因密钥交换失败而拒绝连接
原地升级前必须确认 datadir 文件系统和 GLIBC 版本
CentOS 7.9 可以跑，但 CentOS 6 或某些定制内核的容器镜像会直接启动失败——不是报错，是 mysqld 进程静默退出。原因很硬：8.4 编译依赖 GLIBC 2.17+，且默认启用 clone() 系统调用优化，老内核不支持。
- 查 GLIBC：
ldd --version | grep glibc
，低于 2.17 必须升 OS 或改用逻辑导入方案 - 查文件系统：
df -Th /var/lib/mysql
，XFS/EXT4 安全，Btrfs/ZFS 需额外验证，尤其开启压缩时可能触发 8.4 的元数据校验异常 - 查
innodb_buffer_pool_size：如果设成物理内存的 90%，升级过程中因内存紧张可能导致初始化失败，建议压到 ≤75%
真正麻烦的从来不是命令敲得对不对，而是那些没出现在错误日志里的东西：比如某个凌晨自动执行的报表脚本，用了已被移除的 OLD_PASSWORD() 函数，或者监控脚本里硬编码了 information_schema.PROCESSLIST 的字段顺序——这些只有在真实流量打进来之后才会浮出水面。
