Navicat同步中断90%因服务端主动断链，需同时启用“保持连接间隔=60秒”和“Use Keep Alive”，并调大云数据库空闲超时至1800秒，否则自动重连无效。
navicat 数据同步任务“莫名中断”，90% 不是网络问题，而是数据库服务端主动断链 + 客户端没做心跳保活。它看起来像网络抖动，实际是 mysql 的 wait_timeout 或中间防火墙回收空闲连接导致的静默断开。自动重连只负责“连上”，不负责“续传”，开了也白开——任务照样停在中断点。
为什么“自动重连”开了还断？
自动重连（Auto Reconnect）只是在 TCP 连接意外关闭后尝试重建会话，但它不会恢复正在执行的 SQL 语句，也不会跳过已成功写入的数据。更关键的是：它根本等不到“断”的那一刻——很多中断发生在语句执行中，连接还没彻底丢，但服务端已因超时 kill 掉会话，此时 Navicat 还以为连着，直到下一条语句返回 MySQL server has gone away 才报错。
- 检查目标库当前
wait_timeout值：SELECT @@wait_timeout;（默认常为 28800 秒，但云数据库如阿里云 RDS 默认仅 300 秒） - Navicat 的“自动重连”必须配合“保持连接间隔”（
Keep-alive interval）才有效，否则它连“何时该重连”都判断不了 - 仅勾选
Auto Reconnect而不设Keep-alive interval，实测 4~5 分钟后必断；两者都设为 60 秒，可稳定跑 2 小时以上
怎么配“保持连接间隔”才真正防断？
这不是一个开关，而是一组协同动作。光填数字没用，必须同时启用底层 TCP 心跳。
- 在连接编辑页 → 【高级】选项卡中，把
Keep-alive interval设为60（单位秒），不是0或留空 - 务必勾选
Use Keep Alive—— 这会触发操作系统级 TCPSO_KEEPALIVE，比应用层 PING 更可靠 - 若目标库是云数据库（如腾讯云 CDB、华为云 DCS），还需登录控制台，将「连接空闲超时」从默认 300 秒调大至
1800或更高 - 验证是否生效：同步过程中用
netstat -an | grep :3306（Linux/macOS）或资源监视器（Windows）观察连接状态是否持续，而非频繁重建
同步中途断了，怎么确认是真断连还是假死？
别急着重跑，先看日志末尾那条语句是否执行成功。Navicat 同步日志里每条 INSERT/UPDATE 都带行数和耗时，最后成功的一行就是断点锚点。
- 查目标库最新记录的
id或created_at：SELECT id, created_at FROM your_table ORDER BY id DESC LIMIT 1; - 对比日志里最后一条“successfully inserted X rows”的 ID 值，若一致，说明是服务端断链；若日志停在某条语句前，大概率是锁等待或外键冲突
- 不要依赖“同步完成百分比”——它只按表数量算，不反映单表内实际进度；百万行表卡在 99% 是常态
- 如果日志末尾出现
Lock wait timeout exceeded或ERROR 1452，问题不在连接，而在数据依赖或事务阻塞
真正容易被忽略的是：Keep-alive interval 和 Use Keep Alive 必须同时开启，缺一不可；而云数据库的连接空闲超时设置，必须在控制台改，Navicat 里设再久也没用。
