如何处理MySQL数据库的连接池耗尽问题？-mysql教程-PHP中文网

连接池耗尽主因是应用层未释放连接，而非数据库负载过高；需通过SHOW FULL PROCESSLIST排查慢查询、Sleep连接及存储过程调用，并用try-with-resources确保CallableStatement和ResultSet及时关闭，同时配置leakDetectionThreshold与MySQL的wait_timeout协同防泄漏。

如何处理mysql数据库的连接池耗尽问题？

连接池耗尽不是“连不上”，而是“连上了却回不去”——绝大多数情况是连接被卡在应用层没释放，而不是数据库扛不住。

查 `SHOW FULL PROCESSLIST` 看哪些连接真正在干活

别只盯着 Threads_connected 数值，它只告诉你“有多少连着”，不告诉你“为什么连着”。执行 SHOW FULL PROCESSLIST 后重点看三列：

Command 是 Query 且 Time > 30 秒：大概率是存储过程或慢 SQL 卡住，检查它是否含 SELECT ... FOR UPDATE、未提交事务、嵌套循环或没加索引的 WHERE
Command 是 Sleep 但 Time 持续增长：说明应用拿到连接后没关，或者调用完存储过程没消费全部 ResultSet
Info 字段出现 CALL 开头：确认是不是某个存储过程在拖住连接，记下 Id，后续可针对性 KILL

Java 调用存储过程必须用 `try-with-resources`

漏关 CallableStatement 是生产环境最常复现的泄漏点。JDBC 不会因为你用了连接池就自动帮你关语句对象——Connection.close() 只归还连接，不清理其创建的 CallableStatement 或 ResultSet。

错误写法：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());
}

启用连接泄露检测，60 秒不归还就报警

HikariCP 的 leakDetectionThreshold 不是摆设。设成 60000（60 秒），一旦连接被借出超时未归还，它会在日志里打出完整调用栈，精准定位到哪一行代码拿了连接没还。

kashen-mysql DDLtoExcel

解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。

下载

Druid 对应配置是 removeAbandonedOnBorrow=true + removeAbandonedTimeoutMillis=60000
注意：这个阈值要略大于你最长业务逻辑耗时，否则误杀正常请求；但绝不能设成 0 或 -1（即禁用）
配合 JVM 参数 -Dhikari.leak-detection-threshold=60000 可动态覆盖配置文件

别忽略 MySQL 的 `wait_timeout` 和 `interactive_timeout`

即使应用层代码没问题，这两个参数设得过大（比如默认 28800 秒 = 8 小时），也会让空闲连接长期挂在线上，挤占有效连接数。

线上建议设为 300（5 分钟）：足够覆盖大多数长事务，又不至于让空闲连接赖着不走
修改后需重启 MySQL 或执行 SET GLOBAL wait_timeout = 300（仅对新连接生效）
注意：应用连接池的 maxLifetime 必须小于该值，否则连接池会尝试复用已被 MySQL 主动断开的连接，抛出 Communications link failure

真正难排查的从来不是“谁连多了”，而是“谁连了不放”。连接池耗尽问题里，80% 的根因藏在应用代码的 finally 块之外、try-with-resources 之外、或是存储过程里一个没被 COMMIT 的事务里。