Navicat执行长SQL脚本中途断开，根本原因是客户端未主动发送心跳，导致数据库服务端（如MySQL的wait_timeout）超时强制断连；解决方法是将“保持连接间隔”设为服务端wait_timeout值的1/3～1/2（如服务端为60秒则设≤45秒），并勾选“使用keep alive”以兼顾TCP层保活。
navicat 执行长 sql 脚本中途断开，根本不是网络不稳，而是客户端没“说话”，服务器直接把你踢下线了。
为什么 Keepalive 间隔设太大会掉线
MySQL / PostgreSQL 等数据库默认会关闭空闲连接（比如 wait_timeout=28800，即 8 小时），但 Navicat 并不会主动发心跳——除非你手动打开 保持连接间隔。如果这个值设成 300 秒（5 分钟），而你的脚本执行要 12 分钟，中间有 7 分钟没任何通信，服务器就直接 KILL 连接了，Navicat 不报错，只显示「连接已断开」或卡在最后一条语句。
- Keepalive 间隔必须 严格小于 服务端的
wait_timeout值（建议设为它的 1/3～1/2） - 勾选
使用 keep alive是启用 TCP 层保活，它和「保持连接间隔」是两套机制：前者防中间设备（如 NAT、防火墙）断连，后者防数据库服务端主动回收 - 如果数据库是云厂商托管（如阿里云 RDS、腾讯云 CDB），
wait_timeout往往被限制为 300～600 秒且不可改，这时保持连接间隔必须 ≤ 240 秒才保险
如何确认服务端超时值是否真被生效
别只信 Navicat 设置——得看数据库当前 session 实际生效的值。连上后立即执行：
SELECT @@wait_timeout, @@interactive_timeout;
注意：@@wait_timeout 控制非交互式连接（比如 Navicat 执行 SQL 文件时用的就是它），而 @@interactive_timeout 通常只影响交互式命令行登录。如果你看到 @@wait_timeout 是 60，那 Keepalive 间隔就必须设成 ≤ 45，否则必断。
- 修改服务端 timeout 需重启或动态 SET（部分云数据库不支持动态改
wait_timeout） - Navicat 的「高级」页里填的
保持连接间隔单位是秒，输错成毫秒（比如填 60000）会导致实际间隔过长 - 某些旧版 Navicat（17.0.4+ 更可靠
执行 SQL 文件时还掉线？检查这三项隐藏配置
即使 Keepalive 正常，SQL 文件导入仍可能中断，常见于大文件或含多语句的脚本：
- 取消勾选
在每个运行中运行多个查询：否则 Navicat 会把整个文件当一条语句解析，遇到分号就切分，但某些语法（如存储过程定义里的分号）会被误判，导致解析失败并静默断开 - 确认 MySQL 服务端
max_allowed_packet足够大（比如设为100M），否则单条 INSERT … VALUES (…), (…) 超长时直接报Packet too large并终止进程 - 禁用
自动提交时，Navicat 可能因事务未显式COMMIT或ROLLBACK而卡住；建议脚本开头加SET autocommit = 1;，或确保每段逻辑末尾有明确事务控制
Keepalive 和服务端 timeout 是一对咬合齿轮，差 1 秒都可能脱节。最稳妥的做法：先查 @@wait_timeout，再设 Navicat 间隔为它的 60%，最后用一个 10 分钟空循环 SQL（如 DO SLEEP(600);）验证是否真不断。
