MySQL连接未释放本质是应用层未正确关闭连接，导致连接数增长并可能触发“Too many connections”错误；需通过SHOW PROCESSLIST和SHOW STATUS确认泄漏，修复忘关连接、异常绕过关闭、连接被持有及连接池配置等问题。
MySQL连接未释放，本质是应用层没有正确关闭数据库连接，导致连接数持续增长，最终可能耗尽连接池或达到MySQL的max_connections上限，引发“Too many connections”错误。关键不在MySQL本身，而在应用程序的连接使用逻辑。
确认是否真有连接泄漏
先别急着改代码，用MySQL命令验证当前连接状态：
- 登录MySQL执行：
SHOW PROCESSLIST;，观察大量处于Sleep状态且Time值持续增长的连接（尤其是远超应用正常等待时间的） - 查总连接数：
SHOW STATUS LIKE 'Threads_connected';，对比业务低峰期与高峰期的差异 - 检查历史峰值：
SHOW VARIABLES LIKE 'max_connections';，如果Threads_connected频繁接近该值，风险已存在
常见泄漏场景和修复方向
绝大多数泄漏源于开发中对连接生命周期的疏忽：
-
忘记调用 close()：JDBC中未在
finally块或try-with-resources中关闭Connection、Statement、ResultSet - 异常绕过关闭逻辑：try块抛出异常后，若关闭代码只写在try末尾而没进finally，连接就卡住了
- 连接被意外“持有”：比如把Connection存入静态变量、ThreadLocal未清理、或DAO对象长期缓存连接
-
连接池配置不当：如HikariCP的
connection-test-query未设、leak-detection-threshold未开启，导致泄漏难以及时发现
快速定位泄漏点的方法
不依赖日志也能高效排查：
- 启用连接池的泄漏检测：HikariCP加配置
leak-detection-threshold=60000（单位毫秒），超时未关闭会打印堆栈 - MySQL端配合：设置
wait_timeout和interactive_timeout为较低值（如60秒），让空闲Sleep连接更快被MySQL主动断开，暴露问题 - 应用侧加监控：通过Actuator（Spring Boot）或Micrometer暴露连接池指标，观察
active、idle、total变化趋势 - 代码扫描：搜索项目中所有
new Connection、DriverManager.getConnection或dataSource.getConnection()调用，逐个检查是否有配套close
预防比修复更重要
从工程实践层面减少人为失误：
- 强制使用try-with-resources（Java 7+），自动关闭资源，语法清晰不易遗漏
- 统一使用连接池（如HikariCP），禁用
DriverManager直连；连接池本身具备连接回收、心跳检测、泄露预警能力 - 单元测试中模拟异常路径，验证连接是否仍能释放
- 上线前做连接数压测：单接口反复调用，观察
Threads_connected是否回归基线
连接泄漏不是MySQL的问题，而是应用与数据库交互契约的断裂。盯住连接获取与释放的配对关系，再辅以工具辅助，基本就能稳住连接健康度。
