答案：MySQL连接超时需从服务端参数、客户端行为和网络设置三方面排查。首先检查wait_timeout等参数是否过短，建议设为600秒并持久化配置；其次确保连接池合理设置maxIdleTime和检测机制；再排查防火墙、负载均衡器或云服务的空闲超时限制，启用TCP keepalive维持长连接；最后结合MySQL错误日志与应用日志分析中断原因，调优后通过压测验证稳定性。
MySQL连接超时问题通常表现为客户端无法连接、连接中断或查询执行中突然断开。排查这类问题需要从配置参数、网络状况和应用行为三方面入手，以下是一些关键步骤和建议。
检查MySQL服务器端超时参数
MySQL通过多个超时参数控制连接的生命周期，重点关注以下几个：
- wait_timeout：控制非交互式连接（如应用程序连接）在无操作后保持打开的秒数，默认通常是8小时（28800秒），但某些环境可能设得很短。
-
interactive_timeout：控制交互式连接（如命令行客户端）的空闲超时时间，与
wait_timeout类似。 - connect_timeout：服务器等待连接握手完成的时间，过短可能导致连接失败。
- net_read_timeout / net_write_timeout：分别控制读取和写入操作的超时时间，适用于数据传输阶段。
查看当前设置：
SHOW VARIABLES LIKE '%timeout%';如果wait_timeout值太小（例如300秒），长时间空闲的连接会被自动断开。可临时调整：
建议在my.cnf中持久化配置：
wait_timeout = 600
interactive_timeout = 600
分析客户端连接行为
很多连接超时源于客户端未正确管理连接。常见情况包括：
- 应用使用连接池但未设置合理的最大空闲时间或测试查询。
- 连接用完后未及时关闭，导致资源耗尽或长时间空闲被服务端中断。
- 网络不稳定导致心跳包丢失，连接被误判为失效。
建议：
- 在连接池中启用
testOnBorrow或validationQuery（如SELECT 1）来检测连接有效性。 - 设置连接池的
maxIdleTime略小于MySQL的wait_timeout，避免服务端先关闭。 - 使用支持自动重连的驱动，并合理配置重试机制。
检查网络与防火墙设置
中间网络设备也可能中断长时间空闲的TCP连接：
解决方法：
- 确认网络链路中各环节的超时设置，尽量统一或协调。
- 在客户端启用TCP keepalive，定期发送探测包维持连接活跃。
查看错误日志定位具体原因
MySQL错误日志是排查的第一手资料：
- 查找类似“Got timeout reading communication packets”或“Aborted connection”条目。
- 结合时间戳与应用日志比对，判断是主动断开还是异常中断。
开启慢查询日志和通用日志有助于复现过程，但生产环境慎用通用日志。
基本上就这些。关键是把服务端、客户端和网络三者的超时策略对齐，避免某一方提前切断连接。调参后建议进行模拟压测验证效果。
