必须验证三项硬性前置条件：操作系统版本≥CentOS 7.9/Ubuntu 18.04/Debian 10；当前MySQL 8.0版本≥8.0.37；XA RECOVER返回空结果，否则升级后服务大概率无法启动。

必须验证的三项硬性前置条件

跳过任意一项，升级后大概率卡在启动或连接阶段，不是配置问题，是服务根本起不来：

• 操作系统版本 ≥ CentOS 7.9 / Ubuntu 18.04 / Debian 10（EL6、Debian 9 及更旧系统已被 MySQL 8.4 彻底放弃）
• 当前 MySQL 8.0 版本 ≥ 8.0.37（低于此版本存在已知元数据升级 bug，官方明确不支持升级）
• XA RECOVER 返回空结果（若有未提交 XA 事务，mysqld 启动时会静默 hang 住，不报错也不退出）

用 mysqlcheck 和 MySQL Shell 做预检扫描

不能只靠肉眼读 Release Notes，得让工具跑一遍真实结构：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 执行 mysqlcheck --all-databases --check-upgrade -u root -p，它会直接报出不兼容项，比如仍使用 mysql_native_password 插件的用户账户
• 用 MySQL Shell 运行升级检查器：util.checkForServerUpgrade('root@localhost:3306', {targetVersion:'8.4',password:'your_password'})，它会扫描 100+ 项，包括保留字冲突、废弃语法、performance_schema 表缺失等隐性风险
• 特别注意：如果业务 SQL 里有隐式 GROUP BY 排序（MySQL 8.0 起已移除），这个检查器不会直接标红，但 EXPLAIN 或测试分页结果时会暴露

驱动与客户端兼容性必须实测

很多连接失败不是数据库没起来，是客户端根本握不上手：

• 确认所有 Java 应用使用的 mysql-connector-j 版本 ≠ 8.4.0——该版本存在官方 Bug #115736，ARM64 下固定卡顿 30 秒，x86_64 Linux 也普遍超 2 秒，高并发下触发 SQLNonTransientConnectionException: Got an error writing communication packets
• Python 用户检查是否还在用 PyMySQL 1.0.x 或 mysqlclient 2.1.x 以下版本，它们对 caching_sha2_password 的 handshake 支持不完整，建议升到 PyMySQL 1.1.0+ 或 mysqlclient 2.2.4+
• 运维脚本里硬编码的 --default-auth=mysql_native_password 参数要全部清理，否则即使插件启用也会因认证方式不匹配而失败

备份有效性必须验证，不能只存不试

备份文件存在 ≠ 能恢复。生产环境升级前必须完成一次全链路恢复演练：

• 物理备份（如 Percona XtraBackup）要验证 xbstream 解包 + xtrabackup --prepare + 启动新实例三步连通
• 逻辑备份（mysqldump --all-databases --routines --events）需在干净环境导入并执行 SELECT COUNT(*) FROM mysql.user; 和 SHOW PROCEDURE STATUS; 确认权限和存储过程无丢失
• Binlog 定点恢复要实测：从备份位点往后找 5 分钟 binlog，用 mysqlbinlog 解析并重放，确认关键表数据能精确回退

最常被忽略的是 XA RECOVER 检查和驱动版本核对——前者无声无息导致启动卡死，后者让应用连都连不上，排查时却总往数据库配置上绕。