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