Navicat 16 不校验语法，ERROR 1064 的行号是执行块内相对行号；需结合编码检查（UTF-8无BOM）、分段执行、DELIMITER 处理及 sql_mode 兼容性排查。
navicat 16 无法直接解析备份文件中的语法错误——它只负责执行，不校验；真正能快速定位错误语句的，是结合错误行号、编码检查和分段执行的组合操作。
看懂 ERROR 1064 后面的行号和上下文
Navicat 执行 SQL 备份文件失败时，报错里带的行号（如 near line 127）指的是「当前执行块内」的相对行号，不是整个文件的绝对行号。这是因为 Navicat 默认按分号 ; 切分语句，而备份文件中可能有存储过程定义、注释或函数体里的分号，导致切分错位。
- 打开备份文件，用 VS Code 或 Notepad++ 显示行号，定位到报错提示的「块起始位置」：往前翻找最近一个未被注释的
;或BEGIN，那才是实际执行块开头 - 重点检查该块内：
CREATE PROCEDURE里是否漏了DELIMITER $$；INSERT中是否混入中文引号“”；--注释后有没有紧跟空格（否则部分 MySQL 版本会吞掉下一行） - 若报错含
Unknown database 'xxx'，说明文件开头有USE xxx;但目标库不存在——这不是语法错，而是上下文缺失，需手动创建库或删掉该行
用 UTF-8 无 BOM 编码重存备份文件
Navicat 默认以 UTF-8 解析 SQL 文件，但若文件实际是 GBK 或含 BOM 头，会导致关键字乱码（如 SEL?CT）、引号失配、注释失效，最终触发 ERROR 1064。
- 在 VS Code 中打开备份文件 → 右下角查看当前编码（如显示「GBK」或「UTF-8 with BOM」）→ 点击编码名 → 选择「Save with Encoding」→ 选
UTF-8（明确不含 BOM） - 保存后，在 Navicat 的「运行 SQL 文件」对话框中，务必勾选
使用 UTF-8 编码读取文件（该选项有时默认关闭） - 特别注意：Windows 记事本另存为「UTF-8」时默认带 BOM，必须换编辑器处理，否则仍会解析失败
分段执行缩小问题范围
备份文件通常几千行，靠肉眼扫效率极低。Navicat 不支持跳过错误继续执行，但你可以主动拆解：
- 把文件按 200 行一组复制到新文件，逐个导入；一旦某组报错，再对该组做二分法切分（如先试前 100 行，再试后 100 行）
- 对疑似有问题的段落，在 Navicat 新建查询窗口中粘贴执行——此时错误信息更精准，且可配合语法高亮快速发现括号不闭合、字符串没结束等问题
- 遇到含
DELIMITER的存储过程，整段必须一起执行，不能切开；可临时注释掉其他所有块，只留这个过程测试
检查 sql_mode 和数据库版本兼容性
从 MySQL 5.7 导出的备份，在 8.0+ 环境执行常因严格模式失败，典型表现是插入 '0000-00-00' 或 NOT NULL 字段无默认值时报错，错误类型仍是 ERROR 1064 或 ERROR 1364。
- 连上目标库，执行
SELECT @@sql_mode;，确认是否含STRICT_TRANS_TABLES - 在 Navicat「运行 SQL 文件」窗口中，勾选
在执行前运行自定义命令，填入：SET SESSION sql_mode = ''; - 若仍失败，检查备份文件中是否有
ENGINE=MyISAM（MySQL 8.0+ 默认禁用），需替换为ENGINE=InnoDB
真正卡住的地方往往不是语法本身，而是 Navicat 把「编码错」、「权限缺」、「上下文断」都统一包装成 ERROR 1064。行号只是线索，不是终点；每次重试前，先确认文件编码、目标库状态、以及你正在执行的到底是「一条语句」还是「一个逻辑块」。
