Navicat 连接 MySQL 5.7 隔几分钟断开，是因服务端 wait_timeout 值过小（如云数据库常设为 300 秒），需执行 SHOW VARIABLES LIKE 'wait_timeout' 确认实际值，并在 Navicat「高级」页签设置 Keepalive Interval 为小于该值且留 10 秒余量（如 240 秒），或改用初始化 SQL（SELECT 1）实现更可靠的 SQL 层心跳。
navicat 连接 mysql 5.7 后隔几分钟就断开，不是 navicat 本身故障，而是 mysql 服务端主动切断了空闲连接——wait_timeout 默认值通常为 28800 秒（8 小时），但某些 linux 发行版或云数据库（如阿里云 rds）会调低到 300–600 秒。navicat 的 keepalive interval 设置正是用来对抗这个机制的，但填错数值或忽略服务端限制，反而会让心跳失效。
MySQL 5.7 的 wait_timeout 实际值怎么查
别猜，直接连上后执行：
SHOW VARIABLES LIKE 'wait_timeout';
注意区分 wait_timeout（对非交互式连接生效，Navicat 默认走这个）和 interactive_timeout（仅对 mysql 命令行等交互式客户端有效）。如果你看到返回是 300，那就意味着服务器 5 分钟没收到任何请求就会 kill 掉连接。
常见误区：
- 只改 Navicat 的
Keepalive Interval，却不确认服务端是否允许该心跳频率（部分托管 MySQL 会屏蔽 TCP keepalive 包） - 误以为设成
10秒就一定比30秒更稳——实际上太短可能触发服务器限流或被防火墙丢包
Navicat 中 Keepalive Interval 的正确设置位置
不是在「连接」主界面，也不是在「SSH 隧道」里——它藏在「编辑连接」→「高级」页签底部：
- 勾选
保持连接间隔 - 填入数值（单位：秒），推荐值：
60（1 分钟）或120（2 分钟） - 务必确保该值 小于 你查到的
wait_timeout值，且留出至少 10 秒余量
如果服务器 wait_timeout = 300，填 290 是危险的——网络延迟或 MySQL 负载高时，一次心跳可能超时，下一次还没发出去连接就被关了。
为什么设了 Keepalive 还断？排查这三处
心跳不是万能的，以下情况会让它失效：
-
MySQL 5.7运行在 Docker 容器中，且未加--sysctl net.ipv4.tcp_keepalive_time=60参数，宿主机内核不转发 keepalive 包 - 中间有企业级防火墙（如 Palo Alto、深信服），默认丢弃无 payload 的 TCP keepalive 探针
- Navicat 使用的是 SSH 隧道连接，但隧道配置里没开
ServerAliveInterval，此时真正起作用的是 SSH 层的保活，不是 Navicat 自己的
验证方法：用 tcpdump 抓包看是否有周期性 ACK 包发出（目标端口 3306），没有则说明 keepalive 根本没发出去。
替代方案：SQL 层心跳比 TCP 层更可靠
当 TCP keepalive 被拦截或不可控时，可退回到应用层心跳：
- 在 Navicat 中打开「连接属性」→「常规」→ 勾选
初始化 SQL - 填入：
SELECT 1; - 再打开「高级」→ 勾选
保持连接间隔，设为300（5 分钟）
这样每次空闲接近超时前，Navicat 会自动执行一条轻量查询，MySQL 认为连接活跃，重置 wait_timeout 计时器。虽然不如 TCP 层高效，但在多数云环境和代理环境下更稳定。
真正容易被忽略的是：MySQL 5.7 的 wait_timeout 是会话级变量，如果你用的是连接池或中间件（如 ProxySQL），它可能覆盖了全局设置，得去对应组件里查——不能只盯着 Navicat 或 mysqld.cnf。
