根本原因是mysql的wait_timeout机制将长时间执行的delete视为空闲连接而中断，叠加navicat自身socket timeout、云nat网关超时及ssh隧道心跳失效等多层超时共同导致。
navicat 删除大量数据（如 delete from table where ...）执行超时，根本原因不是语句写错了，而是 mysql 主动中断了连接——它把“长时间运行的 delete”当成空闲连接处理了，触发了 wait_timeout 或 net_write_timeout，而非客户端卡死或网络断开。
为什么 DELETE 会触发 wait_timeout？
很多人误以为 wait_timeout 只对“完全没操作”的连接生效。但 MySQL 实际判定逻辑是：只要当前连接没有返回结果、没有新查询发起、且语句尚未完成提交，就可能被视为空闲。而大范围 DELETE（尤其未加 LIMIT、无索引 WHERE 条件）会锁表、扫描全表、生成大量 undo log，期间客户端等待时间远超默认 28800 秒（8 小时）的阈值——在云数据库或高负载环境下，wait_timeout 常被设为 300～600 秒，几秒不动就 kill 连接。
-
SHOW VARIABLES LIKE 'wait_timeout';查当前值；注意interactive_timeout不影响 DELETE（该参数只用于 mysql 客户端交互式连接） - Navicat 新建连接默认走非交互式协议，所以受
wait_timeout约束，不是interactive_timeout - 即使你手动执行
SET SESSION wait_timeout = 86400;，也必须在连接建立后、DELETE 执行前立即运行，否则无效
Navicat 自身的超时设置会叠加干扰
Navicat 在执行 SQL 时，除了服从 MySQL 的超时规则，还会施加自己的读取限制：Socket Timeout（读取响应超时）和 Read Timeout（高级设置里）。这两项默认常为 30～60 秒，比 MySQL 的 wait_timeout 还短，形成双重掐断。
- 右键连接 → Edit Connection → Advanced → 找到
Socket Timeout (sec)，至少设为 600（10 分钟），千万级数据建议 1800+ - 同页检查是否勾选
Keep connection alive，间隔设为 30～60 秒；不勾选则 Navicat 不发心跳，MySQL 更容易提前断连 - 如果使用 SSH 隧道，
Socket Timeout和 MySQL 的wait_timeout全部失效，必须单独配置 SSH 的ClientAliveInterval和跳板机sshd_config
真正耗时环节不在网络，而在事务与锁
超时只是表象，DELETE 卡住的本质是 I/O + 锁竞争。Navicat 用单条 DELETE 扫描百万行，会持续持有 MDL 锁（元数据锁）和行锁，阻塞其他查询，同时触发磁盘刷写和日志膨胀，MySQL 内部调度变慢，进一步拉长响应时间，最终触发超时。
- 避免直接
DELETE FROM huge_table WHERE status = 0;；改用带LIMIT的分批删：DELETE FROM huge_table WHERE status = 0 LIMIT 10000;，循环执行 - 确保 WHERE 条件字段有索引，否则全表扫描会让超时概率翻倍
- 不要在 Navicat 的“查询窗口”里一次性粘贴多条 DELETE；每条执行完确认影响行数再继续，避免连接状态混乱
- 如果表无主键或唯一索引，DELETE 可能退化为全表扫描+临时表，此时哪怕调大所有超时也难成功，应优先补主键或改用
TRUNCATE（仅限清空）
云数据库场景下最易忽略的 NAT 超时
阿里云 RDS、腾讯云 CDB 等服务背后普遍部署了 NAT 网关，其空闲连接超时固定为 300～900 秒，且用户无法修改。这意味着：哪怕你把 MySQL 的 wait_timeout 设成 86400、Navicat 的 Socket Timeout 设成 3600，只要两次心跳间隔 > NAT 限制，连接照样被中间设备静默断开。
- Navicat 心跳间隔（Tools → Options → Environment → Keep connection alive）必须 ≤ 240 秒（建议设 180）
- 云厂商控制台通常不暴露 NAT 超时值，只能靠更密的心跳兜底；设 300 秒大概率仍会断
- 若已启用 SSH 隧道，NAT 超时由 SSH 层接管，此时 Navicat 的心跳设置完全无效，必须靠 SSH 的
ClientAliveInterval和服务端sshd_config配合
复杂点在于：超时可能来自任意一层——MySQL 服务端、SSH 协议栈、云 NAT、Navicat 客户端。必须逐层确认，不能只调一个参数。最容易被忽略的是 SSH 隧道下的心跳失效，以及云环境里 NAT 超时不可控这一事实。
