连接池耗尽主因是应用层连接泄漏而非数据库性能瓶颈，需通过show full processlist定位慢sql、未关闭连接及存储过程阻塞，并配合leakdetectionthreshold与wait_timeout协同防控，同时合理配置max_connections。
连接池耗尽不是“连不上数据库”，而是“连上了却没还回去”——90% 的 case 是应用层泄漏，不是数据库扛不住。
看 SHOW FULL PROCESSLIST 到底在卡什么
别只盯着 Threads_connected 数值，它只告诉你“有多少连着”，不告诉你“为什么连着”。执行 SHOW FULL PROCESSLIST 后重点盯三列：
-
Command是Query且Time> 30 秒：大概率是慢 SQL、SELECT FOR UPDATE、未提交事务，或存储过程里嵌套循环没加索引 -
Command是Sleep但Time持续上涨：说明应用拿了连接没关，或者调用完存储过程后没消费全部ResultSet -
Info字段以CALL开头：确认是不是某个存储过程拖住连接，记下Id，后续可KILL
Java 调用存储过程必须用 try-with-resources
JDBC 不会因为你用了 HikariCP 就自动帮你关 CallableStatement 或 ResultSet。Connection.close() 只归还连接，不清理它创建的语句对象。
- 错误写法：
cs.execute()后直接return，没关cs，也没处理多结果集 - 正确写法：必须包裹在
try-with-resources中，且显式循环消费所有结果集（存储过程可能返回多个SELECT）
try(CallableStatement cs = conn.prepareCall("{CALL proc_report(?)}")) {
cs.setInt(1, tenantId);
cs.execute();
do {
try(ResultSet rs = cs.getResultSet()) {
if(rs != null) {
while(rs.next()) {/* 处理 */}
}
}
} while(cs.getMoreResults());
}
开 leakDetectionThreshold + wait_timeout 协同防泄漏
leakDetectionThreshold 不是摆设。设成 60000（60 秒），一旦连接被借出超时未归还，HikariCP 会在日志里打出完整调用栈，精准定位到哪一行代码拿了连接没还。
- MySQL 层配
wait_timeout = 300（5 分钟），避免空闲连接长期占位 - 两者要错开：比如 HikariCP 设 60 秒，MySQL 设 300 秒，防止连接被池误判为泄漏而提前关闭
- 注意：MySQL 8.0+ 的
wait_timeout是会话级变量，应用连接初始化时需确保生效
别信 max_connections 默认值，先算清楚再动
MySQL 默认 max_connections = 151，但一个 Java 应用实例配 20 个连接池最大连接，10 个 Pod 就能打满；再加上其他服务共用库，爆满是分分钟的事。
- 查当前真实占用：
SHOW GLOBAL STATUS LIKE 'Threads_connected' - 查每个 IP 连接分布：
ss -ant | grep :3306 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn - 临时扩容慎用：
SET GLOBAL max_connections = 1000可能触发 OOM，优先查泄漏
真正难的不是找到那条没关的 ResultSet，而是它藏在三层回调、异步线程、或者 finally 块里被吞掉的异常里——日志里看不到报错，连接就静默消失了。
