MySQL连接超时主因是客户端、网络、服务端三方协同作用，核心为长空闲后某方主动断连而另一方未感知；服务端wait_timeout默认8小时但常调至300–600秒，客户端连接池需配置有效性检查与保活，中间设备如Nginx、云SLB存在静默断连风险，socketTimeout等参数须合理梯度匹配。

MySQL 连接超时通常不是单一原因导致的，而是客户端、网络、服务端三者协同作用的结果。核心在于：连接建立后长时间无交互，中间某个环节主动断开，而另一方未及时感知或重连。

服务端主动关闭空闲连接（最常见）

MySQL 服务端默认通过 wait_timeout 和 interactive_timeout 参数控制空闲连接生命周期。非交互式连接（如应用连接池中的连接）受 wait_timeout 约束，默认值常为 28800 秒（8 小时），但很多生产环境会调低到 300–600 秒。一旦连接在此期间没有执行任何语句，MySQL 服务端会主动发送 FIN 包终止连接。

• 查看当前值：SHOW VARIABLES LIKE '%timeout%';
• 临时调整（重启失效）：SET GLOBAL wait_timeout = 600;
• 永久生效需修改 my.cnf 中的 wait_timeout 并重启 MySQL

客户端未启用连接保活或校验机制

Java 应用常用 HikariCP、Druid 等连接池，若未配置有效性检查，连接池可能把已断开的连接继续分配给业务线程，导致执行 SQL 时抛出 Connection reset 或 Lost connection 异常。

• HikariCP 推荐配置：connection-test-query=SELECT 1（旧版）或 connection-test-query=/* ping */ SELECT 1（新版支持 ping）
• 启用连接存活检测：test-while-idle=true + time-between-eviction-runs-millis=30000
• 设置连接最大生命周期（避免长期占用）：max-lifetime=1800000（30 分钟）

中间网络设备强制中断长连接

防火墙、负载均衡器（如 Nginx、AWS ALB）、云厂商 SLB 等常内置连接空闲超时策略（如 60 秒、300 秒）。它们不识别 MySQL 协议，仅基于 TCP 连接无数据包流动时间做清理，且不会通知两端，造成“静默断连”。

• 确认路径中所有中间件的空闲超时设置，确保 ≥ 应用侧和 MySQL 的 timeout 值
• 例如：Nginx 代理 MySQL 时需配置 proxy_read_timeout 600; 和 proxy_send_timeout 600;
• 云数据库如阿里云 RDS，其前端代理默认空闲超时为 300 秒，需同步调整应用与 MySQL 的对应参数

客户端 socket 层超时设置不合理

部分驱动或框架允许单独设置底层 socket 超时（如 MySQL Connector/J 的 socketTimeout），若设得过短（如 30 秒），在慢查询或网络抖动时会提前中断，报错类似 Read timed out，这属于读操作超时，而非连接空闲超时。

• JDBC URL 示例：?socketTimeout=30000&connectTimeout=5000
• connectTimeout 控制 TCP 握手阶段超时，socketTimeout 控制后续读写阻塞等待上限
• 建议：该值应略大于业务最长 SQL 执行时间，而非用于解决空闲断连问题

不复杂但容易忽略的是参数匹配——服务端 wait_timeout、连接池 idleEvictTime、中间设备超时、应用 socketTimeout 四者需形成合理梯度，最短的那个往往就是瓶颈点。