navicat连接mysql超时主因是socket timeout、wait_timeout和keep connection alive三项参数未同步调整。需在advanced页设socket timeout为300秒起步，执行set session wait_timeout=28800，并勾选keep connection alive设间隔60秒；ssh隧道或云nat下须额外配置对应心跳。
navicat 连接 mysql 总是超时，绝大多数情况不是网络断了，而是三类超时参数在不同环节“各自为政”，且 navicat 的默认值（30 秒）远低于实际操作所需时间——尤其执行 alter table、大批量导入或复杂查询时。
Socket Timeout 和 wait_timeout 必须同步调大
只改客户端或只改服务端，基本无效。它们控制的是不同链路：
-
Socket Timeout（Navicat 客户端读取超时）：在连接右键 → Edit Connection → Advanced → Socket Timeout(sec)，建议设为300（5 分钟）起步；千万级表建议1800 -
wait_timeout（MySQL 服务端空闲超时）：不能只靠全局配置SET GLOBAL wait_timeout = 28800，Navicat 新建连接不会继承它；必须在 Advanced → SQL Query 框中填入SET SESSION wait_timeout = 28800，确保每次连接一建立就生效
Keep connection alive 不是可选项，是必选项
很多用户开了 Socket Timeout 却没开保活，结果连接在“安静期”被中间设备（如 NAT 网关、SSH 隧道）无声断开：
- Advanced 页必须勾选
Keep connection alive，间隔设为60（单位秒） - 若走 SSH 隧道，Navicat 的这个设置会失效，需改 SSH 配置：
/etc/ssh/sshd_config中加ClientAliveInterval 30和ClientAliveCountMax 3，再重启sshd - 阿里云/腾讯云 NAT 网关常见空闲超时为 300–900 秒，你无法改它，只能靠更密的心跳兜底
DDL 操作卡住 ≠ 网络超时，本质是锁与 I/O
看到“正在执行…”不动，别急着调超时——很可能是 Navicat 在后台执行了阻塞操作：
- 关闭
Preview DDL before execution（Preferences → DDL）：否则会先跑SELECT COUNT(*)，极易被元数据锁（MDL）卡死 - 避免用可视化一次性改多个字段+加索引+改注释：Navicat 会拼成单条
ALTER TABLE，可能触发max_allowed_packet限制或降级为 COPY 算法（全程锁表） - 主键/唯一索引变更慎用界面操作：哪怕 socket 没断，也可能因引擎算法切换（ALGORITHM=INPLACE → COPY）导致数分钟无响应
真正容易被忽略的，是中间层对心跳的劫持——SSH 隧道、云 NAT、甚至某些企业防火墙，会让 MySQL 层和 Navicat 层的超时设置全部失效。调参前，先确认你走的是直连、SSH 还是跳板代理。
