同步任务卡住不动实为连接已死但navicat未察觉，需同时配置keepaliveinterval（小于wait_timeout一半）、wait_timeout（服务端调高）、reconnect when connection is lost（勾选并手动续传），缺一不可。
同步任务卡住不动，其实是连接已死但Navicat没察觉
Navicat 数据同步不主动探测连接健康状态，一旦中间网络设备（如 NAT、防火墙、SSH 跳板）静默断开 TCP 连接，它仍会往这个“假活”连接发 SQL，表现为界面无响应、进度条冻结、日志停在某一行。这不是卡顿，是悬挂——后续所有操作都无效，必须手动杀进程或重启。
必须同时配三个参数：KeepaliveInterval、wait_timeout、Reconnect
只调一个等于白干。三者作用不同，且存在依赖关系：
-
KeepaliveInterval：在 Navicat 连接「高级」页设置，单位秒；它定期发SELECT 1探活，必须小于服务端wait_timeout的一半（例如 MySQL 返回SELECT @@wait_timeout是 60，则这里最大填 30） -
wait_timeout：数据库侧参数，决定空闲连接存活时长；不能只靠 Navicat 心跳，得先确认并调高它（SET GLOBAL wait_timeout = 86400或改my.cnf） -
Reconnect when connection is lost：勾选此项，但注意——它只恢复连接，不续传任务；中断后需手动点「继续」，否则停留在失败那一步
SSH 隧道场景下，客户端和服务端心跳要对齐
走 SSH 的用户常忽略跳板机配置，导致 Navicat 心跳发不出去：
- Navicat SSH 设置页 → 勾选
Keep alive，设为 30 秒 - 跳板机上检查
/etc/ssh/sshd_config：确保有ClientAliveInterval 30和ClientAliveCountMax 3，改完重启sshd - 若跳板机无法修改，换用本地端口转发（
ssh -L 3307:127.0.0.1:3306 user@jump），再让 Navicat 直连localhost:3307，绕过跳板心跳限制
真正防悬挂的底线操作：禁用长事务 + 分片执行
同步过程中若触发大事务（如全表 UPDATE 无 WHERE），连接会长时间处于非空闲态，心跳失效，且服务端可能因超时 KILL 连接：
- 避免在同步前执行
BEGIN；Navicat 默认按语句提交，不要手动开启事务 - 用「高级模式」→ 勾选
自定义记录集→ 按主键分片（如每 10 万行一组），生成dataset_001到dataset_010；某组失败，下次只重跑该组，不重放整个事务 - 跨库迁移时，在「Where Condition」里加时间过滤（如
updated_at > '2026-09-01'），缩小单次传输量，降低悬挂概率
