数据库连接耗尽最常见原因是连接池配置过小且并发请求高，其次为连接未正确关闭、长事务或慢查询阻塞、连接池与数据库最大连接数不匹配。
连接池配置过小但并发请求高
数据库连接耗尽最常见原因是连接池最大值（如 maxPoolSize）设得太低，而应用短时间内发起大量查询。比如 Spring Boot 默认 HikariCP 的 maximumPoolSize 是 10，若接口 QPS 达到 50 且平均响应时间 200ms，理论瞬时连接需求就可能突破 10（50 × 0.2 = 10），实际因排队和重试很容易打满。
实操建议：
- 用数据库侧命令查当前活跃连接数，例如 MySQL 执行
SHOW STATUS LIKE 'Threads_connected';，PostgreSQL 查SELECT count(*) FROM pg_stat_activity; - 检查应用配置中连接池的
maximumPoolSize、connectionTimeout和idleTimeout，避免空闲连接长期不释放 - 压测时监控连接池的
active、idle、pending指标，HikariCP 可通过 JMX 或/actuator/metrics/hikaricp.connections.active获取
连接未正确关闭导致泄漏
Java 中忘记在 finally 块或 try-with-resources 中关闭 Connection、Statement、ResultSet，或 Go 中漏掉 rows.Close()，都会让连接一直被占用，直到超时或进程重启。
典型现象是连接数缓慢上涨，且 SHOW PROCESSLIST（MySQL）里能看到大量 Sleep 状态连接，状态持续几分钟以上。
实操建议：
- 所有 JDBC 调用必须用 try-with-resources，禁止裸调
connection.createStatement() - 检查 ORM 框架是否开启自动提交（
autoCommit=true），否则事务不结束会锁住连接 - Spring 中确认
@Transactional方法没有被同类内非代理方法调用，否则事务失效，连接无法按预期释放
长事务或慢查询阻塞连接释放
一个执行 30 秒的 UPDATE 语句会独占一个连接整整半分钟，期间该连接无法复用。如果这类语句频繁出现，连接池很快被占满，新请求只能等待或失败。
更隐蔽的是隐式事务：比如 MySQL 在 autocommit=false 下执行一条 SELECT 后没提交，后续所有操作都在同一事务中，连接就一直挂着。
实操建议：
- 数据库侧设置超时参数，如 MySQL 的
wait_timeout和interactive_timeout（默认 28800 秒），但不能替代应用层优化 - 给关键查询加
SET SESSION max_execution_time = 5000;（MySQL 5.7+），强制中断超时 SQL - 用
EXPLAIN分析慢查询是否缺少索引，避免全表扫描拖住连接
连接池与数据库最大连接数不匹配
应用端配了 maximumPoolSize=100，但 MySQL 的 max_connections 只有 50，结果一半连接永远拿不到，报错通常是 Too many connections 或 HikariCP 的 Connection is not available, request timed out after 30000ms。
还要注意中间件影响：比如用了读写分离代理（MyCat、ShardingSphere），它本身也维护连接池，会额外消耗后端数据库连接。
实操建议：
- 查 MySQL 当前限制：
SHOW VARIABLES LIKE 'max_connections';，并结合业务预估总连接需求（应用实例数 × 单实例连接池大小 + 代理开销 + 运维工具连接） - 连接数不是越大越好——超过 OS 文件描述符限制（
ulimit -n）会导致创建失败，Linux 默认常为 1024 - 生产环境建议连接池大小设为数据库
max_connections的 60%~80%，留出余量给备份、监控等后台任务
真正难排查的往往是组合问题：比如连接池偏小 + 几个慢查询 + 一处忘了 close，三者叠加才触发耗尽。监控必须覆盖应用连接池指标、数据库活跃连接、SQL 执行时长三个层面，缺一不可。
