确认方法是执行select @@wait_timeout;，若返回300则说明服务端5分钟无请求即断连；keepalive interval应设为该值的1/3～1/2（如90或120秒），且必须小于wait_timeout并留10秒余量。
navicat 备份执行中连接断开，基本不是网络问题，而是 mysql 服务端主动 kill 掉了空闲连接——wait_timeout 值太小，且 navicat 的心跳没跟上。
怎么确认是 wait_timeout 导致的？
别猜，连上后立刻执行：
SELECT @@wait_timeout;
注意：备份任务走的是非交互式连接，生效的是 @@wait_timeout，不是 @@interactive_timeout。如果返回是 300（阿里云 RDS 常见），说明服务器 5 分钟没收到任何请求就会关连接。
- 云数据库（如腾讯云 CDB、华为云 DCS）通常默认设为 300–600 秒，且不让你改全局值
- 本地 MySQL 5.7 默认是 28800 秒，但 Docker 容器或某些运维脚本可能已调低
- 只查配置文件里的
wait_timeout不够，必须查运行时 session 值，因为动态 SET 可能已覆盖
Keepalive Interval 应该设多少才安全？
这个值不是越小越好，也不是填 60 就万事大吉——它必须满足两个硬条件：
- 严格小于你查到的
@@wait_timeout值（比如@@wait_timeout = 300，就不能设 ≥300） - 留出至少 10 秒余量（推荐设为
wait_timeout的 1/3～1/2，如 300 → 填90或120） - 避开中间设备干扰：设成 10 秒可能触发防火墙限流或 NAT 超时丢包，实测 60～120 秒最稳
填错单位是高频坑：Navicat 的 Keepalive Interval 单位是秒，输成 60000 就等于 100 分钟，备份肯定断。
为什么勾选了 “Use Keep Alive” 还断？
“Use Keep Alive” 启用的是操作系统级 TCP SO_KEEPALIVE，它和 Keepalive Interval 是两套机制，必须同时开才完整：
-
Keepalive Interval控制 Navicat 主动发SELECT 1的频率（SQL 层心跳） - “Use Keep Alive” 控制内核是否周期性发 TCP ACK 探针（传输层心跳），防 NAT、防火墙静默回收
- 如果走 SSH 隧道，真正起作用的是 SSH 的
ServerAliveInterval，Navicat 自己的设置无效 - Docker 部署的 MySQL 必须加
--sysctl net.ipv4.tcp_keepalive_time=60，否则宿主机不转发探针
备份中途断了，怎么快速定位断点？
Navicat 备份日志末尾那条成功语句就是锚点，别重跑全量：
- 看日志最后一条带 “completed” 或 “successfully written” 的行，记下对应表名和时间戳
- 进数据库查该表最新记录：
SELECT id, updated_at FROM your_table ORDER BY id DESC LIMIT 1; - 对比日志里最后完成的 ID 或时间，一致就说明是服务端断链；不一致大概率是锁表、外键冲突或磁盘满
- 不要信界面上的进度条——备份进度按表数量算，一张千万行的表卡住，进度永远停在 99%
最易被忽略的一点：云数据库控制台里的「空闲连接超时」设置，必须和 Navicat 侧同步调大，光改客户端没用。
