数据库连接池耗尽问题排查与SQL优化实战

1. 问题现象与初步判断

那天凌晨2点15分，值班手机突然响起刺耳的告警声。打开监控系统一看，生产环境的订单服务已经全线飘红。核心接口响应时间从平时的50ms飙升至30秒以上，最终全部超时失败。更糟糕的是，所有依赖数据库的定时任务也开始集体报错，日志中清一色地出现：

java复制Failed to obtain JDBC Connection; 
nested exception is java.sql.SQLTransientConnectionException: 
swxx - Connection is not available, request timed out after 30000ms.

服务器监控显示CPU使用率已经达到98%，内存使用倒是相对正常。第一反应是执行服务重启，确实短暂恢复了约20分钟，但同样的问题很快再次出现。

注意：这种"重启后暂时恢复，但很快复现"的现象，通常意味着问题不是简单的内存泄漏或资源耗尽，而是存在某种持续性的资源占用或竞争。

2. 错误排查方向：连接泄漏疑云

看到"Failed to obtain JDBC Connection"这个错误，大多数工程师的第一反应都会是数据库连接泄漏。我也不例外，立即采取了以下措施：

2.1 连接池泄漏检测配置

在HikariCP连接池中增加了泄漏检测参数：

yaml复制spring:
  datasource:
    hikari:
      leak-detection-threshold: 60000 # 60秒未关闭连接视为泄漏

同时为Druid连接池配置了类似参数：

properties复制# 开启连接泄漏检测
spring.datasource.druid.remove-abandoned=true
# 180秒未关闭视为泄漏
spring.datasource.druid.remove-abandoned-timeout=180
# 记录泄漏日志
spring.datasource.druid.log-abandoned=true

2.2 连接保活机制

为防止连接因长时间空闲被数据库服务器断开，增加了验证查询：

properties复制spring.datasource.dru