util.checkForServerUpgrade()是Oracle官方唯一推荐且真正覆盖MySQL 5.7→8.0升级风险的预检方式，它能识别utf8mb3字符集、RANK等保留字冲突、caching_sha2_password认证插件兼容性等问题，而mysqlcheck --check-upgrade仅校验表结构损坏，对语义级变更完全无感；必须停用group_replication后执行，需匹配目标版本的mysqlsh、指定configPath、具备足够权限，并严格处理ERROR级问题。
util.checkForServerUpgrade() 是唯一能真正覆盖 MySQL 5.7 → 8.0 升级风险的预检方式，mysqlcheck --check-upgrade 或手工查表结构根本无效——它不报 utf8mb3、不拦 RANK 列名、不发现 caching_sha2_password 认证插件兼容性问题。
必须停掉 group_replication 才能运行检查
util.checkForServerUpgrade() 在组复制启用时会直接报错 ER_GROUP_REPLICATION_PLUGIN_IS_ON，不是警告，是中断退出。
- 对每个待升级节点（从节点优先），先执行 STOP GROUP_REPLICATION;
- 再确认插件已卸载：SELECT PLUGIN_NAME, PLUGIN_STATUS FROM information_schema.PLUGINS WHERE PLUGIN_NAME = 'group_replication';，结果必须为空或 DISABLED
- MGR 集群里主节点留到最后升，避免脑裂或同步中断
命令格式和参数不能错
工具对版本、路径、权限极其敏感，错一个就漏报或失败： -mysqlsh 二进制版本必须 ≥ 目标 MySQL 版本（如升到 8.0.42，就得用 mysql-shell-8.0.42）
- 必须显式传 --config-path 指向真实 my.cnf，否则无法检测废弃配置项（如 query_cache_type）
- 连接用户需具备 RELOAD、PROCESS、SELECT 权限（root 最稳）
- 典型安全调用：./mysqlsh -uroot -p -S /tmp/mysql.sock -e "util.checkForServerUpgrade({targetVersion: '8.0.42', configPath: '/etc/my.cnf'})"报告里的 ERROR 必须处理，WARNING 不代表安全
输出分三级，但只有ERROR 是硬阻断，不修完绝对不能启 8.0：
- ERROR: Usage of utf8mb3 charset → 必须全库执行 ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci
- ERROR: Column name 'rank' is a reserved keyword → 改列名（如 col_rank），反引号包裹只是临时绕过，应用层 SQL 仍可能崩
- WARNING: INVALID_DEFAULT_VALUE_FOR_TABLE → 如 DATETIME DEFAULT '0000-00-00 00:00:00'，8.0 严格模式下建表失败，必须手工 ALTER TABLE ... ALTER COLUMN ... SET DEFAULT ...
- WARNING: INFORMATION_SCHEMA_TABLE_DIFFERS → 比如监控脚本直查 information_schema.PROCESSLIST，8.0 已移到 performance_schema，代码得改
别信自动修复，所有改动都得人工确认
util.checkForServerUpgrade() 只报不改，它甚至不碰数据字典。
- 它不会帮你批量重命名列、不会自动替换字符集、不会删掉 my.cnf 里的 query_cache 行
- 报告里出现任何 PLUGIN_IS_NOT_AVAILABLE，意味着你配置文件还开着已移除插件，MySQL 8.0 启动直接 abort
- 第三方工具（如 Navicat、MyBatis）是否兼容，它完全不感知；得在测试环境跑真实流量验证连接、事务、存储过程行为
真正卡住升级的，从来不是“能不能启起来”，而是“启起来后业务查不到数据”或者“定时任务 silently 失败”。检查只是起点，不是终点。
