navicat 导出大型数据库频繁断开的根源是中间链路（mysql服务端、ssh隧道、云nat网关或navicat自身）主动切断连接；需分别调大navicat的socket timeout、mysql的net_read_timeout和max_allowed_packet，并配置ssh/云平台心跳及禁用navicat“自动断开空闲连接”。
Navicat 导出大型数据库时频繁断开，**不是因为“导出太慢”，而是连接在传输中途被某一层主动切断了**——MySQL 服务端、SSH 隧道、云平台 NAT 网关、甚至 Navicat 自己，都可能在你毫无察觉时悄悄关掉连接。
Socket Timeout 设太短，Navicat 自己先放弃
这是最常被误判的点：报错 Lost connection to MySQL server during query，但其实 MySQL 还活着，是 Navicat 等不及结果主动断开了。
-
Socket Timeout控制的是 Navicat 从 MySQL 读取响应的最大等待时间，默认仅30秒；导出千万行表时，单次SELECT *可能卡在磁盘 I/O 或网络缓冲，远超这个值 - 必须进连接编辑页 → 「高级」选项卡 → 找到
Socket Timeout（单位：秒），设为预估最大查询耗时的 1.5 倍（例如导出最慢一张表要 200 秒，就填300） - 注意：它和「连接超时」（Connection Timeout）无关，后者只管建连阶段，不影响导出中的读取
服务端 net_read_timeout 比 Socket Timeout 更早掐断
就算你把 Navicat 的 Socket Timeout 调到 10 分钟，MySQL 服务端也可能在 30 秒后就把连接干掉了——因为它默认的 net_read_timeout 就是 30。
-
net_read_timeout决定 MySQL 等待客户端读取数据的上限；导出大表时，Navicat 接收大量数据包若出现微小延迟（比如压缩、写磁盘），就会触发该超时 - 建议在 MySQL 服务端执行：
SET GLOBAL net_read_timeout = 600（即 10 分钟），并同步写入my.cnf的[mysqld]段落以持久化 - 别忘了
max_allowed_packet也要调大（如512M），否则 BLOB 字段或长文本会被截断，导致 Navicat 收不到完整结果而静默失败
中间设备静默断连：SSH / 云 NAT / 防火墙才是真黑手
很多用户调完 MySQL 和 Navicat 参数仍失败，问题大概率出在中间链路上——它们根本不会报错，只会在空闲几秒后直接回收 TCP 连接。
- 若走 SSH 隧道：Navicat 的「保持连接活跃」设置无效；必须在跳板机或目标服务器的
/etc/ssh/sshd_config中加ClientAliveInterval 30和ClientAliveCountMax 3，再重启sshd - 若直连阿里云 RDS、腾讯云 CDB 等：查对应文档，其 NAT 网关空闲超时多为
300～900秒，你无法修改，只能靠更密的心跳兜底——Navicat 的KeepaliveInterval必须 ≤ 服务端wait_timeout的一半（例如wait_timeout=300，则此处最大填150） - 务必取消勾选「仅当有查询时发送 ping」：导出过程中有大量解析、拼 INSERT、校验主键等无 query 阶段，勾了等于没设
Navicat 自己“主动断开空闲连接”这个选项最隐蔽也最关键
即使服务端、网络、SSH 全部稳如泰山，Navicat 仍可能在导出间隙突然发 COM_QUIT 关闭连接——它有个默认启用的隐藏行为，叫「自动断开空闲连接」（部分版本显示为 Disconnect when idle）。
- 这个选项不显眼，通常藏在连接编辑页的「高级」或「常规」页底部，但它的优先级高于所有服务端超时设置
- 必须手动取消勾选；否则哪怕
wait_timeout设成 8 小时，Navicat 也会在空闲几十秒后自己断开 - 同时确认「保持连接活跃」已启用且间隔合理（建议
60秒）：既防断连，又不过度刷心跳流量
真正容易被忽略的，是中间层对心跳的劫持——SSH 隧道、云 NAT、企业防火墙，会让 MySQL 层和 Navicat 层的超时设置全部失效。动手调参前，先确认你走的是直连、SSH 还是跳板代理；否则所有参数都是白调。
