Navicat导出超大表中断主因是连接在空档期被SSH、云防火墙或MySQL服务端静默回收；需同步配置Navicat SSH Keep alive（设30）、跳板机sshd_config的ClientAliveInterval 30与ClientAliveCountMax 3、禁用Navicat自动断开空闲连接、调大Socket Timeout与net_read_timeout，并确保系统内存充足。
Linux 端 Navicat 导出超大表中断，八成不是网络断了，而是连接在传输空档期被中间设备静默回收——SSH、云防火墙、MySQL 服务端三者之一先动手，Navicat 后知后觉才报错。
SSH 隧道没配保活，Linux 下最常见断连源头
Linux 用户常通过 SSH 跳转连接内网 MySQL，但默认 SSH 守护进程（sshd）不发保活包。一旦 Navicat 在拼接 INSERT、压缩数据或写磁盘时停顿超过 30 秒（云厂商 NAT 常设 60 秒空闲超时），sshd 直接关闭 TCP 连接，Navicat 下次读取时才触发 Lost connection to MySQL server during query。
- 必须在 Navicat 连接编辑页 → 「SSH」选项卡 → 勾选
Keep alive，并设为30 - 跳板机上改
/etc/ssh/sshd_config：ClientAliveInterval 30+ClientAliveCountMax 3，然后sudo systemctl restart sshd - 别混淆「Keep alive」和「KeepaliveInterval」：前者是 SSH 层心跳，后者是 MySQL 协议层心跳，Linux 下两者都要开
Navicat 自己关掉空闲连接，比服务端更隐蔽
即使 SSH 和 MySQL 都稳如磐石，Navicat 在导出间隙（比如解析完元数据、等待磁盘 I/O）检测到连接空闲，会主动发 COM_QUIT 断开——这个行为在 Linux GUI 环境下更激进，且错误日志里完全不体现。
- 进连接编辑页 → 「高级」选项卡 → 找到
Disconnect when idle（部分版本叫自动断开空闲连接）→ 必须取消勾选 - 同时确认
KeepaliveInterval已启用且值 ≤wait_timeout / 2（查SELECT @@wait_timeout，若返回300，这里最大填150） - 这个选项藏得深，很多用户调高了 MySQL 的
wait_timeout却仍失败，就是漏掉了它
Socket Timeout 和 net_read_timeout 不匹配，断在半路
Socket Timeout 是 Navicat 客户端等 SQL 返回的上限，单位秒；net_read_timeout 是 MySQL 服务端等客户端读取响应的上限。若前者设 300，后者仍是默认 30，服务端 30 秒没收到 Navicat 的 ACK 就直接 kill 连接，Navicat 再等也没用。
- Navicat 连接编辑页 → 「高级」→
Socket Timeout设为预估导出耗时的 1.5 倍（如预计 200 秒，填300） - MySQL 服务端执行：
SET GLOBAL net_read_timeout = 600（建议值），并确认max_allowed_packet≥512M，否则 BLOB 字段传一半就被截断 - 注意：
Socket Timeout控制的是“执行阶段”，和连接建立时的Connection Timeout无关
Linux 系统资源不足导致进程被 OOM Killer 杀掉
Navicat for Linux 默认把整张表加载进内存再压缩写盘，导出千万行以上时，navicat 进程 RSS 内存常飙到 2–4GB。若系统剩余内存不足，Linux 内核的 OOM Killer 会优先干掉它，现象是进程突然消失、无日志、桌面通知都来不及弹。
- 导出前用
free -h确认可用内存 ≥ 导出表估算大小 × 3（例如表 5GB，留 15GB 空闲） - 改导出路径到内存更大的挂载点（如
/mnt/data），避免默认写~/Desktop挤爆根分区 - 实在不行，用
mysqldump --tab或SELECT ... INTO OUTFILE替代，绕过 Navicat 内存模型
真正麻烦的不是参数调多少，而是每个环节的超时值必须形成链条：SSH 保活间隔 wait_timeout / 2 KeepaliveInterval Socket Timeout net_read_timeout。少一环，就在那断。
