Navicat批处理任务报“Lost connection”主因是连接复用下被静默关闭，须同步调整wait_timeout（服务端空闲超时）、Keep connection alive（客户端心跳）和Reconnect when connection is lost（客户端自动重连）三项；大事务未提交、全表扫描、无LIMIT批量操作等SQL易致隐性断连。
Navicat批处理任务中途报“Lost connection to MySQL server”
这不是网络断了，而是连接在任务执行中被悄悄关闭了。Navicat批处理默认复用同一个连接，一旦该连接被MySQL或中间设备（如SSH隧道、云NAT）主动终止，后续SQL仍会往已失效的socket发包，触发Lost connection to MySQL server during query或MySQL server has gone away。
必须同步调整的三个超时参数
只改其中一项基本无效——三者作用层不同，缺一不可：
-
wait_timeout（MySQL服务端）：控制空闲连接存活时间。批处理中若某条SQL执行完后没立刻执行下一条，空闲期超过此值就会被KILL。建议连接建立后立即执行SET SESSION wait_timeout = 28800;（8小时），放入Navicat连接的Advanced → SQL Query框中自动运行 -
Keep connection alive（Navicat客户端）：不是“保持连接”，而是定期发SELECT 1心跳。勾选后设间隔为60秒（不能＞300，否则部分防火墙不认） -
Reconnect when connection is lost（Navicat客户端）：关键开关！仅靠keep-alive无法恢复已断开的连接；必须勾选此项，否则任务卡住就真停了
批处理SQL本身容易导致隐性断连
有些语句会让连接长时间处于非空闲但无有效响应的状态，使心跳失效、重连不触发：
- 大事务未提交：
BEGIN; UPDATE huge_table ...;后忘记COMMIT→ 连接持续占用，wait_timeout不生效，但MySQL可能因max_execution_time或OOM直接KILL进程 - 全表扫描类语句：
EXPLAIN显示type=ALL且rows超百万→ 执行期间连接“活着”但无数据返回，中间链路先超时断开 - 无
LIMIT的批量修改：DELETE FROM logs WHERE created_at → 建议拆成<code>WHERE id BETWEEN ? AND ? LIMIT 10000循环执行
SSH隧道场景下额外要配跳板机
如果Navicat通过SSH连接MySQL，光配Navicat的keep-alive没用，跳板机也会静默断连：
- Navicat SSH配置页：勾选
Keep alive，设为30秒 - 跳板机
/etc/ssh/sshd_config需含：ClientAliveInterval 30和ClientAliveCountMax 3，然后sudo systemctl restart sshd - 验证是否生效：
ss -tnp | grep :22看ESTABLISHED连接是否有timer:(keepalive,30sec,0nsec)
最容易被忽略的是：批处理里混用长耗时DDL（如ALTER TABLE）和DML。DDL期间MySQL会持有元数据锁，连接看似“忙”，实则阻塞在内核态，既不响应心跳也不接受新查询——此时Reconnect机制完全不触发，只能靠调大Socket Timeout硬扛，或把DDL单独拆出任务流。
