必须验证三项硬性前置条件：操作系统版本≥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，得让工具跑一遍真实结构：
- 执行
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或测试分页结果时会暴露
驱动与客户端兼容性必须实测
很多连接失败不是数据库没起来，是客户端根本握不上手：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 确认所有 Java 应用使用的
mysql-connector-j版本 ≠8.4.0——该版本存在官方 Bug #115736，ARM64 下固定卡顿 30 秒，x86_64 Linux 也普遍超 2 秒，高并发下触发SQLNonTransientConnectionException: Got an error writing communication packets - Python 用户检查是否还在用
PyMySQL1.0.x 或mysqlclient2.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 检查和驱动版本核对——前者无声无息导致启动卡死，后者让应用连都连不上，排查时却总往数据库配置上绕。
