Navicat备份远程MySQL频繁中断，90%因服务端主动kill连接且Navicat未发心跳，导致“假活着”直至语句执行报“MySQL server has gone away”；需同步配置客户端Keep-alive间隔60秒+启用Use Keep Alive，并调大服务端wait_timeout、net_read_timeout至1800秒以上。
Navicat 备份远程 MySQL 数据库时频繁中断，90% 不是网络本身掉包，而是服务端主动 kill 连接 + Navicat 没发心跳，导致连接“假活着”直到语句执行失败才报错。
为什么“Lost connection to MySQL server during query”总在备份中途出现
备份过程本质是长事务+大量 SELECT + 文件写入，但 Navicat 默认不发任何保活信号。MySQL 服务端（尤其是云数据库）看到连接空闲超时（如阿里云 RDS 默认 wait_timeout=300），直接终止会话。此时 Navicat 还以为连着，直到下一条 SELECT 或 INSERT 才收到 MySQL server has gone away——所以错误总卡在某张表的中间。
- 云环境更敏感：腾讯云 CDB、华为云 DCS 等默认空闲超时普遍设为 300~600 秒，远低于本地 MySQL 的 28800 秒
- Navicat 的“自动重连”只重建连接，不续传备份进度，重连后从头开始，等于白忙
- net_read_timeout 默认仅 30 秒，导出大表时单次读取超时就会中断，而非等待
Navicat 客户端必须配的两个保活参数
光开“自动重连”没用，必须组合启用底层心跳机制：
-
保持连接间隔设为60（单位秒），不能为 0 或留空 - 务必勾选
使用 Keep Alive——这会触发操作系统级SO_KEEPALIVE，比应用层 PING 更早探测断连 - 这两个设置在连接编辑页的“高级”选项卡里，改完需重新测试连接才生效
服务端必须同步调大的关键 timeout 参数
客户端保活只是“喊话”，服务端得愿意听。仅调 Navicat 设置，若服务端仍 5 分钟就断，照样无效：
Mysql Skill 1.0.0 (3)
下载
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
- 查当前值：
SELECT @@wait_timeout, @@interactive_timeout, @@net_read_timeout; - 动态生效（无需重启）：
SET GLOBAL wait_timeout = 86400;、SET GLOBAL interactive_timeout = 86400;、SET GLOBAL net_read_timeout = 600; - 云数据库必须进控制台手动调高「连接空闲超时」，例如阿里云 RDS 需设为 ≥1800 秒，否则客户端心跳再勤也白搭
备份中断后怎么快速定位断点而不是重跑
别急着删备份文件重来。Navicat 日志里每条表导出都带成功行数和时间戳，这是唯一可信锚点：
- 翻到日志末尾，找最后一条
successfully exported X rows from `table_name` - 去目标库执行：
SELECT MAX(id), COUNT(*) FROM table_name;，对比行数和最大 ID 是否与日志一致 - 若一致，说明是服务端超时断链；若不一致，大概率是锁表、外键约束或某条记录损坏（可单独导出该表验证）
真正难处理的是“静默断连”：连接状态看起来正常，但服务端已回收会话，Navicat 直到下一条 SQL 才暴露问题。这种场景下，客户端保活 + 服务端 timeout 同步放宽，缺一不可。
