必须用mysqlsh的util.checkForServerUpgrade()检查，它是Oracle官方唯一推荐、能识别utf8mb3废弃、caching_sha2_password认证插件、保留关键字（如rank）、SQL模式变更等跨版本语义问题的前置工具；mysqlcheck仅校验表结构，完全无法覆盖这些高发兼容性风险。
必须用 mysqlsh 的 util.checkForServerUpgrade() 检查，其他工具（如 mysqlcheck）完全无效。它不是可选项，而是 Oracle 官方唯一推荐、能识别跨大版本语义变更的前置检查方式。跳过这步，等于在生产环境盲升。
为什么非得用 util.checkForServerUpgrade() 而不是 mysqlcheck
mysqlcheck --check-upgrade 只校验表结构是否损坏（比如 .frm 文件匹配、触发器 definer 是否为空），对 5.7→8.0 的真实高发问题完全无感：
-
utf8mb3字符集被标记为废弃 →mysqlcheck不扫描 -
caching_sha2_password认证插件不被老客户端支持 →mysqlcheck不检测 - 列名
rank、json在 8.0 成为保留关键字 →mysqlcheck不报错 -
NO_AUTO_CREATE_USER等 SQL mode 已移除 →mysqlcheck不验证配置项
mysqlsh 版本和连接方式必须严格匹配
工具本身不是“装了就能用”，硬性前提缺一不可：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 使用的
mysql-shell二进制版本必须 ≥ 目标 MySQL 8.0 版本（例如要升到8.0.42，就得用mysql-shell-8.0.42；混用 5.7 的 shell 会漏检） - MySQL 5.7 实例必须正在运行，且优先走本地 socket 连接：
./mysqlsh -uroot -p -S /tmp/mysql.sock（比 TCP 更稳定，避免 DNS 或防火墙干扰） - 连接用户需具备
SUPER权限和全库SELECT权限（root最稳） - 若启用 SELinux（CentOS/RHEL），需确认
mysqld进程上下文未被重置，否则 shell 连接可能被拒绝
执行命令与报告解读要点
典型命令示例（带配置文件路径，确保参数检查生效）：
./mysqlsh -uroot -p -S /tmp/mysql.sock -e "util.checkForServerUpgrade({'targetVersion':'8.0.42','configPath':'/etc/my.cnf'})" > upgrade_report.log
报告分三级，处理优先级明确：
-
ERROR 级别必须全部修复才能继续：例如
Usage of utf8mb3 charset→ 批量执行ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci；Column name 'rank' is a reserved keyword→ 改列名；caching_sha2_password plugin not supported by client→ 升级应用驱动（如mysql-connector-java ≥ 8.0.13）或提前切认证插件 -
WARNING 级别不能跳过：比如提示某个用户账户用了已废弃的
sql_mode值，或配置中存在 8.0 已移除的query_cache_type，这些不修启动时会直接失败 -
overallStatus必须是OK，否则不要进入下一步升级动作
真正容易被忽略的是：检查结果依赖于当前运行中的 5.7 实例状态——如果它已经启用了 caching_sha2_password（比如手动改过用户认证方式），util.checkForServerUpgrade() 就会如实报出客户端兼容性风险；但如果你没跑这个检查，上线后应用连不上才去排查，就晚了。
