Navicat报“连接已断开”本质是MySQL服务端主动关闭空闲连接，非网络故障；根本原因是wait_timeout触发（如云数据库常设为300秒），Navicat复用失效连接句柄导致“Lost connection”错误；需同步调高服务端wait_timeout、设置Navicat保持连接间隔为服务端值的1/3～1/2，并启用TCP Keep Alive双机制保活。
Navicat执行SQL报“连接已断开”不是网络卡，是MySQL服务端主动KILL了连接
根本原因不是navicat“掉线”，而是mysql服务端在空闲后关闭了连接句柄，navicat仍试图复用它——此时再发sql就会触发lost connection to mysql server during query或mysql server has gone away。关键要区分：这不是客户端故障，而是服务端超时机制生效。
先确认当前会话实际生效的超时值：SELECT @@wait_timeout, @@interactive_timeout;
注意：@@wait_timeout控制Navicat执行SQL文件这类非交互式连接；@@interactive_timeout只影响命令行登录等交互式场景。
- 若返回
@@wait_timeout是300（即5分钟），而你的脚本执行需8分钟，那必然断开 - 云数据库（如阿里云RDS）通常将
wait_timeout硬性设为300～600秒且不可改，必须适配客户端 - 本地MySQL可临时调高：
SET SESSION wait_timeout = 28800;，或永久修改配置文件中的wait_timeout = 28800
Navicat“保持连接间隔”设多少才有效
这个值不是越小越好，也不是越大越省资源，而是必须严格小于服务端wait_timeout，且建议设为它的1/3～1/2。
- 服务端
wait_timeout = 300→ Navicat设240秒（4分钟）最稳妥 - 设成
300或更大：两次心跳之间仍可能被服务端回收 - 设成
30：虽能保活，但每30秒发一次SELECT 1，对高并发连接池可能造成干扰 - 输错单位：填
60000以为是60秒，实际是6万秒（16.7小时），等于没设
为什么勾选“使用Keep Alive”还不够
使用Keep Alive和保持连接间隔是两套独立机制，缺一不可：
-
保持连接间隔：Navicat主动发SQL心跳（如SELECT 1），防MySQL服务端断连 -
使用Keep Alive：启用TCP层保活，防中间设备（NAT、防火墙）静默丢弃空闲连接 - 只开其中一个，仍可能在某一层被断开；云环境尤其需要两者都启用
- 旧版Navicat（如16.x）对Keep Alive支持不稳定，建议升级到17.0.4+
执行长SQL脚本中途断开的隐藏陷阱
即使心跳设置正确，脚本仍可能在第500行突然中断——这往往不是超时问题，而是解析或事务残留导致。
- 取消勾选
在每个运行中运行多个查询：否则Navicat会把整个文件当一条语句切分，遇到存储过程里的分号就误判语法错误并静默终止 - 检查
max_allowed_packet：若脚本含超长INSERT，服务端报Packets too large会直接中断，需设为100M以上 - 事务未结束：脚本开头没写
SET autocommit = 1;，又没显式COMMIT或ROLLBACK，连接卡在事务中，wait_timeout不生效，但资源被占，最终被服务端KILL - 心跳无效的典型场景：连接正卡在锁表或大事务里，Navicat认为“连接还活着”，不会触发重连，手动断开再连是最直接解法
SHOW PROCESSLIST里对应连接的状态，而不是只盯着Navicat的设置。
