MySQL 5.7 升级到 8.0 前检查不兼容 SQL 语法，最可靠的方法是使用 MySQL Shell 自带的 util.checkForServerUpgrade() 工具，而不是仅依赖 mysqlcheck。mysqlcheck 只能检查表物理损坏，无法识别保留字冲突、字符集变更或 SQL 模式差异等语义级问题。

命令速用版

安装 MySQL Shell 8.0+ 后，连接正在运行的 5.7 实例执行以下命令生成兼容性报告：

mysqlsh -uroot -p -S /tmp/mysql.sock -e "util.checkForServerUpgrade({targetVersion: '8.0.41', outputFormat: 'JSON'})"

若无法使用 MySQL Shell，可手动检查保留字和 sql_mode：

SELECT @@sql_mode; SELECT table_schema, table_name, column_name FROM INFORMATION_SCHEMA.COLUMNS WHERE column_name IN ('rank', 'over', 'desc');

为什么会这样

mysqlcheck 设计目的是维护存储引擎物理结构，不解析 SQL 语义。它只能发现索引断裂或页校验失败，对 5.7→8.0 的语法变更完全无感知。真正导致升级后报错的通常是语义级问题，如 8.0 新增保留字 rank、默认启用 STRICT_TRANS_TABLES 模式、或 utf8mb3 字符集废弃，这些都需要 util.checkForServerUpgrade() 这类逻辑层扫描器才能识别。

分步处理

第一步：运行官方扫描器
使用 MySQL Shell 连接 5.7 实例，执行 util.checkForServerUpgrade()。报告中标记为 ERROR 的条目必须修复，如列名冲突或字符集不兼容。WARNING 级别建议处理，如客户端驱动不支持 caching_sha2_password 认证插件。

第二步：人工核对配置差异
检查应用连接配置和初始化脚本。若含 NO_AUTO_CREATE_USER 需删除，该模式在 8.0 已移除。确认 default_authentication_plugin 设置，老客户端可能需显式指定 mysql_native_password。

第三步：清理系统库与备份
不要直接 mysqldump `--all-databases`。5.7 的 mysql 库结构与 8.0 不同，导入旧系统库会导致启动失败。仅导出业务库，并确保备份包含可回滚的 SQL 文件。

怎么验证是否生效

查看 util.checkForServerUpgrade() 输出末尾的 overallStatus 字段，必须为 OK 才可继续升级。在测试环境导入备份数据后，运行业务核心查询语句，观察是否报 ERROR 1064 语法错误或 ERROR 1364 字段默认值错误。检查错误日志中是否有 InnoDB 字典升级失败或认证插件加载失败的记录。

常见坑

误信 mysqlcheck 一切正常就代表能升级，结果上线后 SELECT 语句因保留字报错。直接覆盖导入含 mysql 库的备份，导致 8.0 实例权限系统损坏。忽略 sql_mode 变更，原本能插入的空字符串在 8.0 严格模式下被拒绝。未升级 JDBC 驱动，连接新实例时因认证插件不匹配被拒绝。

常见问题

mysqlcheck 能检查 SQL 语法兼容性吗？

不能。它只检查表物理结构完整性，不分析 SQL 语法或语义兼容性，必须配合 mysqlsh 工具使用。

升级后查询报语法错误怎么办？

检查是否使用了 8.0 保留字作为列名，如 rank 或 over，需重命名列或使用反引号包裹。

老客户端连不上 8.0 实例如何解决？

将 default_authentication_plugin 改回 mysql_native_password 或升级客户端驱动至支持 caching_sha2_password 的版本。

参考来源

MySQL 版本升级与兼容性检查技术资料、MySQL 官方升级文档及社区验证资料