Navicat导出大表报“Lost connection”主因是Socket Timeout默认30秒过短，需设为预期查询耗时1.5倍；同时调高服务端net_read_timeout（建议600）、max_allowed_packet（如512M），并启用KeepaliveInterval（≤wait_timeout一半）且关闭自动断开空闲连接。
Navicat导出大表时Socket Timeout默认30秒太短
导出大表卡在“正在导出…”然后报lost connection to mysql server during query，大概率不是网络断了，而是navicat等不及结果——它的socket timeout默认仅30秒，而一条select *扫千万行可能耗时远超这个值。
- 该参数控制SQL执行阶段的等待上限，和“连接超时”（Connection Timeout）完全无关，后者只管建连那几十秒
- 必须进连接编辑页 → 「高级」选项卡 → 找到
Socket Timeout（单位：秒），设为预期最大查询耗时的1.5倍（例如预估最慢导出要120秒，填180） - MySQL服务端
net_read_timeout也得同步调高（建议至少600），否则服务端先掐断，Navicat再长的Socket Timeout也无效
KeepaliveInterval没设或设得太大
导出中途常有几十秒空闲（比如Navicat在拼接INSERT语句、校验主键、压缩数据），此时若无保活包，中间防火墙/NAT/云厂商网关会直接回收TCP连接，现象是突然断开且无错误日志。
- 在连接「高级」页勾选
保持连接活跃，并设置KeepaliveInterval为60（不能高于服务端wait_timeout的一半；先查SELECT @@wait_timeout，若返回300，这里最大只能填150） - 务必取消勾选
仅当有查询时发送ping——导出解析阶段无query，勾了等于白设 - 如果走SSH隧道，还需同步配置SSH的
ServerAliveInterval 30和ClientAliveInterval 30，否则保活包根本发不到数据库
Navicat自己主动断开空闲连接
即使服务端和网络都稳如泰山，Navicat仍可能在导出间隙“自作主张”关闭连接——它有个隐藏行为：检测到连接空闲超时后直接发COM_QUIT，下次再用就得重连，导致卡顿或中断。
- 打开连接编辑窗口 → 「高级」页（部分版本在「常规」页底部）→ 找到
自动断开空闲连接（或叫Disconnect when idle）→ 取消勾选 - 这个选项不显眼，但比调服务端参数更关键：很多用户调高了
wait_timeout却仍失败，就是漏掉了它 - 同时确认
保持连接活跃已启用且间隔合理（建议60秒，既防断连又不过度刷流量）
服务端net_read_timeout和max_allowed_packet不足
导出大表时，服务端读取结果集或传输大量BLOB字段失败，也会表现为“连接丢失”，实际是net_read_timeout超时或max_allowed_packet被截断，Navicat收不到完整响应。
-
net_read_timeout建议设为600（10分钟），动态生效命令：SET GLOBAL net_read_timeout = 600; -
max_allowed_packet至少设为512M（尤其含TEXT/BLOB字段），命令：SET GLOBAL max_allowed_packet = 536870912; - 永久生效需改MySQL配置文件，在
[mysqld]下加这两行，然后重启服务
Socket Timeout和KeepaliveInterval、它自己的自动断开空闲连接开关、以及服务端的net_read_timeout和max_allowed_packet——少一个，导出就可能在某个环节静默失败。
