“Lost connection to MySQL server during query”绝大多数不是网络中断，而是MySQL服务端主动断连，主因是wait_timeout或interactive_timeout超时、max_allowed_packet不足、大事务阻塞或SSH/NAT静默断连；Navicat持有失效socket继续发SQL即报此错。
为什么Lost connection to MySQL server during query不是网络断了
这个错误绝大多数时候和“网络中断”无关，而是 mysql 服务端主动 kill 掉了连接。典型触发条件是：wait_timeout 或 interactive_timeout 到期、max_allowed_packet 不够、大事务卡住连接不释放、或者中间 ssh/nat 设备静默断连。navicat 仍拿着已失效的 socket 句柄发 sql，自然报错。
wait_timeout 和 interactive_timeout 怎么查和改
先确认当前值：
SHOW VARIABLES LIKE 'wait_timeout';<br>SHOW VARIABLES LIKE 'interactive_timeout';
常见问题：
- 云数据库（如阿里云 RDS）通常禁止
SET GLOBAL，只能通过控制台修改参数组 - 本地或自建库可临时生效：
SET SESSION wait_timeout = 28800; - 永久生效需改配置文件，在
[mysqld]段加：wait_timeout = 28800，然后重启 mysqld - 注意：
wait_timeout控制非交互式连接（如 Navicat 自动任务），interactive_timeout控制交互式连接（如手动查询窗口），两者建议设为相同值
Navicat 侧必须开的三个开关
光调服务端没用，客户端必须配合：
- 编辑连接 → “高级” → 勾选
Reconnect when connection is lost：这是真重连，比心跳更关键 - 同页勾选
Keep connection alive，值设为60（不要勾“仅当有查询时发送 ping”，同步/导出阶段无 query，不勾等于白开） - 工具 → 选项 → 环境 → “保持连接间隔”设为略小于服务端
wait_timeout（例如服务端是 300 秒，这里设 240）
这三个缺一不可——只开一个，大概率还是断。
容易被忽略的隐性断连诱因
即使心跳和重连全开了，以下情况仍会断且不触发重连：
- 执行无
LIMIT的DELETE FROM logs WHERE created_at ：连接长期占用，<code>wait_timeout不起作用，但服务端可能因超时直接 KILL -
ORDER BY status, created_at LIMIT 20却只有status单列索引：触发Using filesort，拖慢执行，中间链路先断 - 事务未结束：
BEGIN后没COMMIT或ROLLBACK，连接卡在非空闲态，心跳无效，自动重连不触发 - 走 SSH 隧道时，跳板机
/etc/ssh/sshd_config缺少ClientAliveInterval 30和ClientAliveCountMax 3，SSH 层先断，MySQL 层根本收不到请求
真正麻烦的不是参数本身，而是这些“连接看似活着、实则已废”的状态——它不报错，也不重连，就卡在那里等 timeout。遇到同步中途挂住，优先手动断开再重连，比等自动恢复更可靠。
