“MySQL server has gone away”本质是服务端主动回收空闲连接，Navicat未启用TCP SO_KEEPALIVE（须勾选Use Keep Alive且设interval为60）、云数据库空闲超时默认仅300秒、旧驱动兼容MySQL 8.0+握手失败，三者未对齐导致假死断连。
MySQL server has gone away 这类报错不是网络断了，而是连接被服务端静默杀掉了——Navicat 还以为连着，下一条语句才暴露问题。90% 的“自动断开”根本不是客户端掉线，是服务端主动回收空闲连接，而 Navicat 没做有效心跳。
为什么“保持连接间隔”设了60秒还断？
只填数字不勾选 use keep alive，等于白配。这个选项控制是否启用操作系统级 tcp so_keepalive，没它，navicat 发的 ping 包只是应用层查询（比如 select 1），容易被防火墙或中间设备过滤，且无法穿透云数据库的连接空闲超时策略。
-
Keep-alive interval必须设为 60（不能为 0 或留空） - 必须勾选
Use Keep Alive，否则保活机制不生效 - 若目标库是阿里云 RDS、腾讯云 CDB 等，仅客户端配没用：需登录控制台，把「连接空闲超时」从默认 300 秒调至
1800秒以上 - 验证方式：同步中执行
netstat -an | grep :3306，观察连接状态是否持续，而非频繁重建
怎么确认断点是真断连还是锁/冲突卡住？
别急着重跑全量任务。先看 Navicat 同步日志最后一行成功记录，例如：successfully inserted 1247 rows，再查目标表最大 id 或最新 created_at：
SELECT id, created_at FROM your_table ORDER BY id DESC LIMIT 1;
- 若日志末尾 ID 和表里最新 ID 一致 → 大概率是服务端 kill 会话导致的假死
- 若日志停在某条 INSERT 前，且后续无报错 → 可能是外键约束失败、唯一索引冲突或行锁等待超时
-
SELECT @@wait_timeout查当前会话超时值；云数据库常为 300 秒，远低于本地 MySQL 默认 28800 秒
驱动版本不匹配也会导致“间歇性断连”
Navicat 自带旧版 MySQL 驱动（如 mysql-connector-java-5.1.x）连 MySQL 8.0+ 时，可能在重连阶段因 caching_sha2_password 插件握手失败而静默丢连接，现象就是“操作几秒后突然断”，日志里却无明确错误。
- 去 Navicat 官网下载对应版本的最新驱动，如
mysql-connector-j-8.0.33.jar - 关掉 Navicat，替换安装目录下
drivers/mysql.jar（Windows 路径示例：C:\Program Files\PremiumSoft\Navicat Premium 16\drivers\） - 重启后，在连接编辑页的【高级】→【驱动】下拉框中确认已识别新版本
- 特别注意：驱动更新后，需重新测试长事务和空闲 5 分钟以上场景，旧驱动的问题往往只在这些边界触发
