navicat数据同步中途断连大概率是tcp空闲连接被中间设备主动掐断，需同步配置navicat客户端（keep alive设为60秒并启用）、ssh隧道（serveraliveinterval 30秒）及云数据库空闲超时（如调至1800秒）三处心跳机制。
navicat 数据同步中途断连，大概率不是数据库挂了，而是 tcp 空闲连接被中间设备（nat、防火墙、ssh 跳板机）主动掐断——网络抖动只是诱因，根本问题是保活机制没配对。
同步任务卡在“正在传输…”后报 connection timeout
这不是 Navicat 本身卡死，而是底层 TCP 连接在无数据交换数秒后被回收。同步大表时，Navicat 可能花几十秒解析元数据、构建 INSERT 批次或等待服务端响应，期间若无任何数据包发出，中间链路就直接断开连接。
- 现象：错误信息常为
Lost connection to MySQL server during query或Connection timed out，但数据库日志里查不到异常，SHOW PROCESSLIST也看不到对应连接残留 - 关键判断：用
Test-NetConnection（PowerShell）或telnet测试端口仍通，说明服务活着；但同步一卡就断，基本锁定为空闲超时 - 必须同步检查三处心跳：Navicat 客户端、SSH 隧道（如有）、数据库服务端——只调其中一处无效
Navicat 连接页的 Keep Alive 必须启用且设为 ≤60 秒
Navicat 的“保持连接活跃”不是可选项，是跨网段/云环境同步的刚需。它的作用是在连接空闲时发 TCP-level 的 ACK 包，欺骗中间设备“连接还在用”。
- 路径：编辑连接 → “高级”选项卡 → 勾选
保持连接活跃 - 值设为
60：必须小于云厂商 NAT 超时（阿里云/腾讯云默认 300 秒，AWS 为 350 秒），但不宜低于15，否则增加无效流量 - 务必取消勾选
仅当有查询时发送ping：同步过程中解析阶段无 query，不勾掉就等于没开 - 注意：
连接超时字段（默认 30 秒）只控制建连阶段，对已建立连接的空闲断连完全无效
走 SSH 隧道时，客户端和服务端 SSH 配置都要改
如果 Navicat 连接配置里勾了“使用 SSH 隧道”，那控制权就在 SSH 协议栈，MySQL 的 wait_timeout 再大也没用——连接早在抵达数据库前就被跳板机或防火墙回收了。
- Navicat SSH 页：启用
Keep alive并设为30秒（对应 OpenSSH 的ServerAliveInterval 30） - 跳板机（SSH 服务器）上：编辑
/etc/ssh/sshd_config，确保有ClientAliveInterval 30ClientAliveCountMax 3
然后执行sudo systemctl restart sshd - 本地 SSH 客户端（如用 OpenSSH）：可在
~/.ssh/config中加 Host 段，写入ServerAliveInterval 30和ServerAliveCountMax 3
同步导出时禁用 Commit every batch + 调大 Batch size
小批次提交（如默认 100 行/批）在跨网段下反而更慢：每次提交都触发一次远程事务确认 + SSL 握手（若启用），网络抖动时极易超时。应让单次传输承载更多数据，减少交互次数。
- 导出向导 → “高级”页 → 取消勾选
Commit every batch：让整个同步过程在一个事务里完成，避免频繁刷盘和认证开销 -
Batch size设为5000～10000：数值越大，单位数据的握手成本越低；但需避开max_allowed_packet限制（MySQL 默认 4MB，建议设为1073741824） - 优先选
Server export (SQL file)而非Client export：数据全程在服务端流转，不经过 Navicat 本地内存，彻底规避本地带宽和延迟影响
真正容易被忽略的是中间层——比如你调好了 Navicat 和 MySQL，却忘了云厂商安全组里“连接空闲超时”是独立配置项（阿里云 RDS 控制台 → 参数设置 → tcp_keepalive_time），它不随数据库参数变化。同步前务必确认这一层也放行了长连接。
