Navicat 15 的 SQL 解析器比 MySQL 服务端更严格，因其使用自研轻量级解析器，不支持 MySQL 特有注释（如/*!40101 SET NAMES utf8mb4 */）、DELIMITER、用户变量赋值、部分 CTE 及 8.0+ 排序规则，且对 BOM、零宽字符等编码异常零容忍，导致静默报错。
Navicat 15 的 SQL 解析器比 MySQL 服务端更严格
Navicat 15 自带的语法校验模块不是 MySQL，它用的是自己实现的轻量级 SQL 解析器，不支持 MySQL 特有注释、动态变量、部分条件编译指令，也不识别服务端才理解的运行时语法（如 /*!40101 SET NAMES utf8mb4 */）。你看到的“语法错误”基本都来自这个解析器，而非 MySQL 报错。
常见触发点包括：
-
/*! ... */格式的 MySQL 扩展注释会被当成非法 token，尤其出现在文件开头或SET语句里 -
DELIMITER $$后面紧跟存储过程定义时，Navicat 不识别该指令，直接把后续内容当普通语句解析 - 含
@variable := ...或SELECT @a := 1这类用户变量赋值，在 Navicat 解析阶段就被判为语法错误 - 某些版本对 CTE（
WITH子句）支持不完整，尤其嵌套多层或含递归时
「运行 SQL 文件」功能会跳过开头的 SET 语句
即使你在 SQL 文件最前面写了 SET autocommit = 0; 或 SET NAMES utf8mb4;，Navicat 15 的「运行 SQL 文件」功能在执行时默认忽略这些语句——它只把它们当“元信息”，不真正发送给服务端执行。结果就是：字符集没生效 → 中文乱码；自动提交没关 → 每条 INSERT 都单独提交 → 极慢且易中断。
解决方法只有两个：
- 改用「新建查询」窗口：全选复制粘贴整个文件内容，再点运行（确保
START TRANSACTION;和COMMIT;包含在内） - 手动删掉文件开头所有
SET、USE、CREATE DATABASE类语句，只保留纯 DML（INSERT/UPDATE）或已确认兼容的 DDL
文件编码与不可见字符导致静默解析失败
Navicat 15 对 UTF-8 BOM、Windows 行尾（\r\n）、零宽空格（U+200B）、软连字符（U+00AD）等非常敏感。MySQL 命令行客户端能容忍大部分，但 Navicat 解析器遇到就直接报“第 X 行附近语法错误”，且不提示具体字符问题。
排查建议：
- 用
file -i dump.sql（Linux/macOS）或 PowerShellGet-Content dump.sql -Encoding UTF8 -Raw | Format-Hex查看真实编码和控制字符 - 用 VS Code 或 Notepad++ 打开，开启“显示所有字符”，重点检查开头和分号后是否有空格、换行、BOM
- 强制转成无 BOM 的 UTF-8：
iconv -f utf-8 -t utf-8//IGNORE dump.sql | sed '1s/^\xEF\xBB\xBF//' > clean.sql
Navicat 15 不支持 MySQL 8.0+ 默认排序规则写法
如果你的 dump 来自 MySQL 8.0+（比如用 mysqldump --set-gtid-purged=OFF 导出），文件头常含类似 SET NAMES utf8mb4 COLLATE utf8mb4_0900_as_cs; 这种语句。Navicat 15 的解析器不认识 COLLATE 后缀里的 _0900_as_cs，直接报错。
临时绕过办法：
- 把这行替换成兼容写法：
SET NAMES utf8mb4; - 或者删掉整行，改在 Navicat 连接配置里手动指定字符集（连接 → 编辑连接 → 高级 → 默认字符集）
- 注意：不要只改
utf8mb4_0900_as_cs为utf8mb4_general_ci，后者在 8.0+ 已被标记为 deprecated，可能引发隐式转换警告
