mysql连接无法释放导致执行中断_配置wait_timeout与连接池优化

MySQL连接卡在Sleep状态是因应用未正确关闭连接且服务端wait_timeout与连接池配置不匹配所致；需确保close()调用、max-lifetime<wait_timeout、启用连接验证及事务规范管理。MySQL 连接卡在 sleep 状态不释放，查 show processlist 一堆 Sleep这是典型的连接未正确关闭 + 服务端超时配置不匹配导致的积压。MySQL 服务端默认 wait_timeout=28800（8 小时），但应用层如果用连接池却从不显式 close() 或没配空闲回收，连接就会一直挂着，直到服务端主动 kill——而这个 kill 恰好发生在你执行下一条语句前，报错 Lost connection to MySQL server during query 或 MySQL server has gone away。实操建议：先确认当前值：SHOW VARIABLES LIKE 'wait_timeout';，开发环境可临时调低到 60 秒快速暴露问题应用代码里所有 Connection、Statement、ResultSet 必须在 finally 或 try-with-resources 中 close()，漏一个就可能 leak别依赖“连接池会自动清理”——HikariCP 默认 connection-timeout=30000，但空闲连接存活时间由 idle-timeout 控制，默认 10 分钟，仍远大于常见业务响应时间HikariCP 的 max-lifetime 和 MySQL wait_timeout 必须错开如果两者相等或 max-lifetime ≥ wait_timeout，连接池会把一个已被 MySQL 关闭的连接再分配出去，下次使用直接抛异常。这不是 bug，是设计如此：连接池只管“自己没过期”，不管“数据库侧是否还接受它”。实操建议：max-lifetime 必须严格小于 wait_timeout，建议留 30–60 秒缓冲，比如 MySQL 设为 3600（1 小时），HikariCP 就设 3500同时打开 connection-test-query=SELECT 1（MySQL 8.0+ 推荐用 isValid()）和 test-on-borrow=true，但注意这会增加每次获取连接的延迟更轻量的做法是关掉 test-on-borrow，改用 keepalive-time=30000（每 30 秒发一次 SELECT 1 检活），配合 validation-timeout=3000Spring Boot + MyBatis 下，事务未结束就 return 导致连接不归还常见于 Controller 层直接返回 ResponseEntity<List>，但 Service 方法加了 @Transactional，MyBatis 的 SqlSession 绑定在线程上，return 后方法虽结束，事务还没提交/回滚，连接就被卡住——尤其遇到流式查询、分页 count 查询后紧跟 list 查询时特别容易触发。 跃问 跃问是由阶跃星辰开发的免费AI智能问答助手，随时帮你智能搜索、高效阅读、识图理解、和你畅聊感兴趣的话题。