必须用mysqlsh的util.checkForServerUpgrade()，它是Oracle官方唯一推荐的5.7→8.0升级前检查工具；mysqlcheck仅校验表结构，无法识别utf8mb3、caching_sha2_password、保留字等跨版本语义变更。
必须用 mysqlsh 的 util.checkForServerUpgrade()，不是 mysqlcheck
mysqlcheck --check-upgrade 只校验表结构是否损坏，对 utf8mb3、caching_sha2_password、保留字（如 rank）完全无感。它报“OK”，不代表你能顺利启 8.0。真正能识别跨大版本语义变更的，只有 util.checkForServerUpgrade()——这是 Oracle 官方唯一推荐且实际有效的预检方式。
运行前三个硬性前提缺一不可
工具不是扔条命令就能跑通的，漏掉任一条件都会导致漏检或报错：
-
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最稳；从8.0.21起，最低要求是RELOAD、PROCESS、SELECT）
命令写法与参数差异直接影响报告完整性
不带参数直接执行会默认检查当前连接实例，但容易遗漏配置文件问题。推荐显式传参：
./mysqlsh -uroot -p -S /tmp/mysql.sock -e "util.checkForServerUpgrade({'targetVersion':'8.0.42','configPath':'/etc/my.cnf'})" > upgrade_report.log
关键点：
-
targetVersion必须填你实际要升的目标小版本号（如8.0.42），不能写8.0或留空，否则可能跳过该版本特有的检查项（比如8.0.34新增的 JSON 函数兼容性） -
configPath必须指向你生产环境真实的my.cnf（或my.ini），否则无法识别已废弃参数（如query_cache_type、explicit_defaults_for_timestamp） - 输出重定向到文件更可靠，避免终端缓冲截断长报告
报告里只有一类问题必须处理完才能启动 8.0
输出分 ERROR、WARNING、NOTE 三级，但只有 ERROR 是阻断项：
-
ERROR: Usage of utf8mb3 charset→ 批量执行ALTER DATABASE db_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci -
ERROR: Column name 'rank' is a reserved keyword→ 改列名，不能靠引号绕过（8.0 中rank是真保留字，语法解析层就报错） -
ERROR: caching_sha2_password plugin not supported by client→ 不是改 MySQL 配置就行，得同步升级应用驱动（如mysql-connector-java ≥ 8.0.13，PyMySQL ≥ 0.10.0）
漏掉任何一个 ERROR 就启 8.0，大概率卡在 “Starting MySQL” 或秒退——日志里往往只显示 “unknown variable” 这类模糊提示，根源却在检查报告里清清楚楚写着。
