Navicat批量执行SQL卡住或报错Connection lost的根本原因是连接池复用导致事务状态、游标或连接句柄残留。需在每文件末加COMMIT/ROLLBACK、禁用Auto-commit、拆分文件、设Keep-alive、避免LOAD DATA、慎用USE、确保UTF-8无BOM编码，并清理Cache/Temp缓存及重建连接栈。
Navicat 批量执行 SQL 文件卡住或报错 Connection lost
根本原因通常是连接池复用时残留了前一个文件的事务状态或未关闭的游标，尤其在多个 .sql 文件里混用 begin/commit、临时表或变量声明时。navicat 的「批量执行」不是简单串行运行，它默认复用同一连接并尝试保持上下文，一旦某个文件出错（比如语法错误或锁等待超时），后续文件会继承异常状态。
实操建议：
- 在每个
.sql文件末尾显式加上COMMIT;或ROLLBACK;，避免事务跨文件污染 - 禁用「自动提交」选项：右键连接 →「连接属性」→「高级」→ 取消勾选
Auto-commit，改由脚本自己控制 - 把大文件拆成小块，单个文件不超过 500 行；含
CREATE TEMPORARY TABLE的必须独占一个文件
执行中途提示 MySQL server has gone away（但手动连没问题）
这不是网络问题，而是 Navicat 缓存了过期的连接句柄。批量执行时，它不会主动探测连接有效性，而 MySQL 的 wait_timeout 默认 8 小时，但实际受中间代理、防火墙或云数据库连接池策略影响，可能几分钟就断开。
实操建议：
- 修改 Navicat 连接配置：「连接属性」→「高级」→ 设置
Keep-alive interval (seconds)为60 - 在每个 SQL 文件开头加一句
SELECT 1;，强制刷新连接活性（对某些云 MySQL 如阿里云 RDS 必须加） - 避免在批量任务中使用
LOAD DATA INFILE—— 它会绕过连接保活机制，直接触发断连
SQL 文件里有 USE database_name; 却切换失败
Navicat 批量执行时，USE 语句只对当前连接生效，但多个文件之间不保证连接一致；更麻烦的是，如果前一个文件末尾有未提交事务，USE 会被挂起直到事务结束。
实操建议：
- 彻底放弃在 SQL 文件里写
USE，改用 Navicat 界面左上角手动切换目标数据库，再执行批量任务 - 若必须用
USE，确保它出现在每个文件第一行，且前面没有注释或空行（Navicat 对 BOM 和 UTF-8 空格敏感） - 检查文件编码：必须是
UTF-8 without BOM，用 VS Code 或 Notepad++ 确认，否则USE后面的分号可能被吞掉
重置 Navicat 缓存后仍无效？重点清这三个地方
Navicat 的缓存不止存在 UI 配置里，真正卡住执行的是本地会话快照和 SQL 解析缓存，光重启没用。
实操建议：
- 关闭 Navicat，删除目录：
%AppData%\PremiumSoft\Navicat\下的Cache和Temp文件夹（Windows） - Mac 用户删：
~/Library/Caches/com.premiumsoft.navicat.*和~/Library/Application Support/PremiumSoft/Navicat/ - 关键一步：打开 Navicat 后，先新建一个测试连接，执行一条
SELECT VERSION();，再关掉它——这会重建底层连接栈，旧缓存才真正释放
最易被忽略的是 SQL 文件里的隐藏字符和跨平台换行符。Windows 写的 .sql 传到 Mac 版 Navicat 执行，\r\n 可能被解析成非法符号，导致整批中断。别信“看起来一样”，用 hexdump -C file.sql | head 看前几行确认换行符类型。
