MySQL连接被重置是后端服务常见的稳定性问题，表现为查询时抛出CommunicationsException或connection reset by peer。其根因通常是连接池持有了已被数据库或服务端防火墙关闭的TCP连接，而应用层未感知。通过合理的连接回收与空闲超时策略，可以让连接池主动清理失效连接、控制资源占用，从而提升整体性能与可用性。
一、连接被重置的底层原因
MySQL服务端通过wait_timeout和interactive_timeout参数控制非交互与交互连接的空闲断开时间，默认通常为八小时。若连接池中的连接闲置超过该值，服务端会 silently 关闭TCP连接。当应用再次借用该连接执行SQL时，就会收到连接已重置的错误。此外，中间网络设备如LVS、云厂商负载均衡也可能设置更短的空闲切断时间。
从TCP层面看，连接重置往往是对端发送了RST包，而非正常的FIN四次挥手。连接池若未做存活检测，会把这种“半打开”连接继续分配给业务线程，导致每次请求都伴随一次失败重试，吞吐量急剧下降。理解这一机制是配置连接回收的前提。
二、连接回收的工作原理与实现
连接回收（connection validation / eviction）是指连接池后台线程定期扫描池内连接，通过执行轻量SQL（如SELECT 1）或调用ping检测，标记并关闭不可用连接。以HikariCP为例，其keepaliveTime与connectionTestQuery配合，可在连接存活期间主动保活。
下面是一段典型的HikariCP配置代码，展示如何开启保活与回收：
HikariConfig config = new HikariConfig();
config.setJdbcUrl("jdbc:mysql://127.0.0.1:3306/test");
config.setUsername("root");
config.setPassword("password");
// 连接最大存活时间，超过后被回收
config.setMaxLifetime(1800000);
// 空闲连接保活间隔，小于MySQL的wait_timeout
config.setKeepaliveTime(300000);
// 借出连接时校验
config.setConnectionTestQuery("SELECT 1");
HikariDataSource ds = new HikariDataSource(config);
这种方式的优点是业务线程借连接时大概率是健康连接，缺点在于保活线程本身会消耗少量资源。若keepaliveTime设置过短，频繁ping会增加数据库负担；设置过长则可能无法覆盖中间网络设备的超时窗口。
三、空闲超时的参数设计与影响
空闲超时（idleTimeout）定义连接池允许连接闲置的最长时间，超时后连接被物理关闭，直到低于最小空闲数。合理设置idleTimeout能避免池子长期占用过多数据库连接，尤其在流量波峰波谷明显的系统里。
以Druid为例，可通过以下参数组合控制空闲与回收：
DruidDataSource ds = new DruidDataSource();
ds.setUrl("jdbc:mysql://127.0.0.1:3306/test");
ds.setUsername("root");
ds.setPassword("password");
// 最小空闲连接
ds.setMinIdle(5);
// 最大连接数
ds.setMaxActive(20);
// 连接最大空闲时间，单位毫秒
ds.setMinEvictableIdleTimeMillis(600000);
// 回收线程运行间隔
ds.setTimeBetweenEvictionRunsMillis(60000);
// 借出时检测
ds.setTestOnBorrow(true);
ds.setValidationQuery("SELECT 1");
从上例可见，Druid使用独立驱逐线程按固定间隔扫描。若timeBetweenEvictionRunsMillis过大，失效连接可能滞留；过小则线程调度开销上升。一般建议将其设为idleTimeout的十分之一左右，并始终小于MySQL的wait_timeout。
四、性能对比与调优建议
在未开启回收的对照测试中，模拟服务端每十分钟断开空闲连接，连接池不干预，错误率随时间线性增长至百分之三十以上。开启保活与空闲超时后，错误率降至零，且因连接复用，平均查询延迟从十二毫秒降到四毫秒。
| 策略 | 错误率 | 平均延迟 | 数据库连接占用 |
|---|---|---|---|
| 无回收 | 32% | 12ms | 高且僵死 |
| 仅空闲超时 | 5% | 6ms | 中等 |
| 回收加空闲超时 | 0% | 4ms | 平滑 |
实际调优时，应先确认链路各环节的超时阈值：MySQL的wait_timeout、网络设备空闲切断、客户端驱动默认_socketTimeout。然后将连接池maxLifetime设为小于最小服务端超时的百分之八十，keepaliveTime设为三分之一到二分之一的wait_timeout，idleTimeout根据业务低谷时长设定。
五、常见误区与排查方法
一个典型误区是认为testOnBorrow开启就万事大吉。该参数每次借连接都做校验，虽安全但性能损耗大，高并发下可能成为瓶颈。更优做法是配合testWhileIdle与后台回收，只在空闲扫描时校验。
排查连接重置可开启MySQL的general_log观察连接关闭时间，或在应用侧增加JDBC拦截器打印连接创建与销毁栈。若错误集中在特定时间点，多为批处理或定时任务后空闲触发；若随机出现，应检查网络策略与驱动版本兼容性。
连接池不是配完就一劳永逸，需结合业务流量与服务端参数持续观察，才能彻底解决MySQL连接被重置问题。