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 四者需形成合理梯度，最短的那个往往就是瓶颈点。
