关系数据库怎么排查连接泄漏

在**关系型数据库（MySQL / PostgreSQL / Oracle 等）**中，**连接泄漏（Connection Leak）**通常指：

应用获取了数据库连接，但未能正确关闭（未 release / 未 return 到连接池），导致连接数持续增长，最终耗尽连接池或数据库最大连接数。

下面从 现象 → 定位 → 根因 → 解决 四个层面讲怎么排查。

一、先确认是不是连接泄漏

1. 观察连接数趋势

-- MySQL
SHOW STATUS LIKE 'Threads_connected';

-- PostgreSQL
SELECT count(*) FROM pg_stat_activity;

-- Oracle
SELECT COUNT(*) FROM v$session;

典型特征：

• 连接数随时间持续上涨
• 无业务高峰也上涨
• 重启应用后恢复正常，不久又上涨

二、数据库侧定位“谁”在泄漏

1. 查看当前连接来源（IP / 用户 / 程序）

-- MySQL
SELECT
  host, user, count(*)
FROM information_schema.processlist
GROUP BY host, user;

-- PostgreSQL
SELECT
  client_addr, usename, count(*)
FROM pg_stat_activity
GROUP BY client_addr, usename;

重点看：

• 某个应用服务器 IP 连接数异常多
• 同一个用户大量空闲连接

2. 查看“空闲但长时间不释放”的连接

-- MySQL
SELECT *
FROM information_schema.processlist
WHERE command = 'Sleep'
ORDER BY time DESC;

-- PostgreSQL
SELECT *
FROM pg_stat_activity
WHERE state = 'idle'
ORDER BY backend_start ASC;

异常信号：

• Sleep / idle 状态超过几分钟甚至几小时
• 数量持续增长

三、应用侧排查（最关键）

1. 是否使用连接池

常见连接池：

• Java：HikariCP / Druid / DBCP
• Go：database/sql
• Python：SQLAlchemy / psycopg2

检查连接池配置是否合理：

maxPoolSize
minIdle
connectionTimeout
idleTimeout
maxLifetime

连接泄漏 ≠ 连接池小
连接池只是“延迟爆炸”

2. 代码是否“用完即关”

错误示例（泄漏）：

Connection conn = dataSource.getConnection();
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(sql);
// 忘了 close

正确写法：

try (Connection conn = dataSource.getConnection();
     Statement stmt = conn.createStatement();
     ResultSet rs = stmt.executeQuery(sql)) {
    // 自动关闭
}

排查重点：

• 异常分支（catch 中是否关连接）
• 多线程 / 异步任务
• 事务未提交或回滚

3. 使用连接池监控（强烈推荐）

HikariCP

开启监控：

spring:
  hikaricp:
    register-mbeans: true

查看指标：

• active
• idle
• pending

Druid

/druid/index.html

可看到：

• 活跃连接
• 泄漏 SQL
• 执行时间最长 SQL

四、常见连接泄漏原因总结

✅ 典型根因：

1. 忘记 close() 连接 / Statement / ResultSet
2. 异常未回滚事务
3. 长事务占用连接
4. 连接池配置错误（不回收空闲连接）
5. 线程池 + 数据库连接混用不当
6. 批量任务未限制并发

五、快速止血方案（生产可用）

1. 设置数据库侧自动断开空闲连接

   -- MySQL
   wait_timeout = 300
   interactive_timeout = 300
   

2. 设置连接池最大存活时间（小于数据库 timeout）

3. 临时重启泄漏应用实例

六、推荐排查流程（实战）

1. 数据库看连接数和来源 IP
2. 确认是否 idle 连接持续增长
3. 定位到具体应用服务器
4. 打开连接池监控
5. 审查代码 try-catch / 资源关闭
6. 加监控 + 单元测试验证

如果你愿意，可以告诉我：

• 用的什么数据库（MySQL / PG / Oracle）
• 什么语言 & 连接池
• 是否有监控指标截图或配置

我可以直接帮你针对性分析泄漏点。