sql连接泄漏本质是应用获取连接后未正确关闭，导致连接池耗尽、新请求超时阻塞；需从数据库活跃连接数、连接池指标、代码规范（try-with-resources/using）、日志与超时配置四方面协同排查。
SQL连接泄漏本质是“借了不还”——应用从连接池获取连接后，未正确关闭（close），导致连接长期被占用、无法复用。久而久之，池中可用连接耗尽，新请求卡在 getConnection() 上，报错如 “Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool”。排查关键不在数据库本身，而在代码逻辑与连接池协同机制。
看连接数趋势：从数据库端快速确认泄漏存在
直接查数据库当前活跃连接，是最直观的起点：
- MySQL 执行：
SHOW STATUS LIKE 'Threads_connected';或SELECT COUNT(*) FROM information_schema.processlist WHERE USER = 'your_app_user'; - SQL Server 执行：
SELECT * FROM sys.dm_exec_sessions WHERE is_user_process = 1; - 重点观察：应用启动后连接数是否持续单边上涨；重启应用后是否回落；是否存在大量
Command = 'Sleep'且Time > 300的闲置连接
盯紧连接池指标：用原生端点或监控工具定位异常
现代连接池（如 HikariCP、Druid）都暴露运行时指标，无需埋点即可诊断：
- Spring Boot + HikariCP：访问
/actuator/metrics/hikaricp.connections，关注hikaricp.connections.active和hikaricp.connections.idle是否长期失衡 - Druid：通过内置监控页面（默认
/druid/index.html）查看“活跃连接数”“等待连接线程数”“泄露次数”统计 - 关键信号：active 持续高位、idle 接近 0、connection acquire timeout 次数突增
代码层兜底：确保每次获取都对应一次释放
90% 的泄漏源于资源释放遗漏。必须统一规范写法：
- Java 推荐 try-with-resources：自动 close Connection/Statement/ResultSet，即使抛异常也不漏
- C# 使用 using 块包裹
SqlConnection、SqlCommand、SqlDataReader - 避免在 finally 外手动 close；禁止在 catch 中吞掉 close 异常；禁止将 Connection 存为类成员变量跨方法复用
- 特别注意异步场景：.NET 的
ExecuteReaderAsync后仍需显式reader.Close()或using，不能只靠 GC
加日志+设超时：让泄漏行为“现形”
被动等报错不如主动暴露问题：
- 在连接获取和归还时打日志（例如 “[GET] connId=123 from pool” / “[RETURN] connId=123 to pool”），配合 traceId 可快速定位未归还路径
- 连接池配置强制回收策略：
maxLifetime（如 30 分钟）、leakDetectionThreshold（HikariCP 支持毫秒级检测，默认关闭，建议设为 60000 即 60 秒） - 数据库侧设置
wait_timeout（MySQL）或user connections限制，倒逼应用暴露长连接问题
