必须用mysqlsh的util.checkforserverupgrade()，它是oracle官方唯一推荐的5.7→8.0升级前置检查工具，可识别utf8mb3字符集、保留字冲突、caching_sha2_password插件不兼容等语义级问题；mysqlcheck仅校验表结构损坏，对上述高发风险完全无感。
必须用 mysqlsh 的 util.checkForServerUpgrade()，不是 mysqlcheck
mysqlcheck --check-upgrade 只能发现表结构损坏或存储引擎不兼容（比如 MyISAM 表），对 utf8mb3 字符集、RANK 列名冲突、caching_sha2_password 插件不支持、SQL mode 变更等语义级问题完全无感。这些才是升级失败的高发原因。
真正有效的检查必须用 MySQL Shell 8.0+（推荐 8.0.33 或更高）连接正在运行的 5.7 实例执行 util.checkForServerUpgrade()。低版本 mysqlsh（如 5.7 或 6.0）会报 TypeError: util has no attribute 'checkForServerUpgrade'。
- 连接必须走本地 socket：
mysqlsh -uroot -p -S /tmp/mysql.sock，避免 SSH 隧道或代理干扰 - 账号需具备
SUPER权限和所有库的SELECT权限 - 执行前确保
group_replication插件已停用，否则报ER_GROUP_REPLICATION_PLUGIN_IS_ON
检查时哪些参数最关键
默认调用会扫描全部库和配置，但生产环境必须过滤噪声，否则误报多、耗时长。核心是传入 config 对象：
-
targetVersion: "8.0.42"：写具体小版本，别写"8.0"——不同 8.0.x 对NO_ZERO_DATE、utf8mb3的处理有差异 -
excludeSchemas: ["test", "tmp_log", "archive_2023"]：传数组，跳过测试库、日志库、归档库 -
outputFormat: "JSON"：比默认表格输出更易解析，方便配合jq自动提取 ERROR -
configPath: "/etc/my.cnf"：让工具校验配置文件里是否含废弃参数（如query_cache_type）
完整命令示例：mysqlsh --uri root@localhost:3306 --sql -e "util.checkForServerUpgrade({targetVersion: '8.0.42', excludeSchemas: ['test_db'], outputFormat: 'JSON', configPath: '/etc/my.cnf'});"
报告里哪些 ERROR 必须人工处理
util.checkForServerUpgrade() 输出分 ERROR/WARNING/NOTE 三级，只有 ERROR 是阻断项，不修完就不能启动 8.0：
-
ERROR: Usage of utf8mb3 charset→ 批量执行ALTER TABLE tbl CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci -
ERROR: Column name 'rank' is a reserved keyword→ 列名必须改（如col_rank），不能只加反引号包住 -
ERROR: Plugin 'query_cache' is not available→ 删除 my.cnf 中的query_cache_type和query_cache_size -
ERROR: The storage engine for the table is not supported→ MyISAM 表必须先转 InnoDB：ALTER TABLE tbl ENGINE=InnoDB
WARNING 级别（如 caching_sha2_password plugin not supported by client）要评估客户端驱动版本：mysql-connector-java 或 <code>PyMySQL 就得升级或临时降级认证插件。
检查后还漏了什么关键动作
检查报告只是起点，下面三件事不做，照样启动失败：
- 运行
mysqld --defaults-file=/etc/my.cnf --validate-config，它能直接定位到配置文件里哪一行含废弃参数（比如expire_logs_days），比看错误日志快得多 - 确认
innodb_file_per_table=ON已启用——8.0 要求每个表一个 .ibd 文件，否则升级时可能卡在数据字典初始化 - 查
mysql.user表里是否有弱密码用户：validate_password插件在 8.0 默认启用且策略更严，升级后可能无法登录
最常被忽略的是：检查本身不改任何数据，也不验证 SQL 执行逻辑是否受影响。比如 GROUP BY 隐式排序在 8.0 被移除，即使检查通过，上线后业务查询也可能出错——这只能靠回归测试覆盖。
