navicat不解析sql内容，所谓“查询文件合并冲突”实为手动合并后暴露的语义冲突，需从合并前（统一utf-8无bom编码、清除bom）、合并中（删冗余use、统一只保留首个use和set names utf8mb4、校准delimiter）、执行时（取消“遇错停止”、勾选“执行前先use”、调高超时）三处协同解决。
navicat 本身不解析 sql 文件内容，所谓“查询文件合并冲突”不是 navicat 报的错，而是你手动合并多个 .sql 文件后执行时暴露的语义冲突——比如重复 use、字符集混用、bom 头不一致、或 insert 主键撞车。解决它得从合并前、合并中、执行时三处动手。
合并前必须统一编码和 BOM 状态
Navicat 默认按 UTF-8 without BOM 解析 SQL 文件。一旦混入带 BOM 的文件（常见于 Windows 记事本保存），它会在“正在执行”状态卡死，无报错也无日志。
- 用 VS Code 或 Notepad++ 打开每个
.sql文件，右下角确认编码为UTF-8（不是UTF-8 with BOM） - PowerShell 快速检查 BOM：
Get-Content -Path init.sql -Encoding Byte | Select -First 3，若输出239 187 191（即EF BB BF），说明有 BOM，需另存为无 BOM - Linux/macOS 可用
file -i *.sql批量识别编码和 BOM
合并时删掉冗余 USE 和 SET NAMES
多个开发者脚本常各自带 USE database_name; 和 SET NAMES utf8mb4;。合并后若第 3 个文件又切库，后面所有语句就全跑偏了；而 SET NAMES utf8; 在 MySQL 8.0+ 配合 utf8mb4_0900_as_cs 排序规则时会直接拒执。
- 只保留第一个文件开头的
USE，其余全部删除 - 统一用
SET NAMES utf8mb4;替换所有SET NAMES行（包括utf8、gbk等） - 如果脚本含存储过程，确认所有
DELIMITER声明一致（如都用$$），否则 Navicat 无法正确切分语句
执行合并文件时必须关掉“遇错停止”
Navicat 的「停止执行遇到错误时」选项是反直觉命名：勾选 = 遇错即停；取消勾选 = 出错继续。这是让合并脚本能跨过单条 INSERT 冲突、继续执行后续语句的唯一控制点。
- 在「运行 SQL 文件」对话框中，务必取消勾选该选项
- 同时勾选「执行每个语句前先执行 USE 语句」，否则跨库对象（如
db1.table1）会报Table doesn't exist - 若文件 >50MB，提前在 Navicat「选项 → 环境 → SQL 执行超时时间」里调高至 600 秒以上，避免超时中断
真正麻烦的从来不是怎么合并，而是合并后才发现某张表在三个脚本里被建了三次、或某个 INSERT IGNORE 被漏替换了——这些隐性冲突不会报语法错，只会静默覆盖或跳过，等业务出问题才暴露。所以每次合并，都该用文本工具快速扫一眼 CREATE TABLE 和 INSERT INTO 的分布密度。
