MySQL连接池泄漏排查与优化实战

银河系李老幺

1. 问题现象与初步判断

上周五凌晨2点37分，我正睡得迷迷糊糊时被一阵急促的报警短信惊醒。监控系统显示生产环境的MySQL数据库连接数突然飙升到上限，导致新请求全部阻塞。打开电脑查看详细指标时，连接池使用率曲线像坐了火箭一样垂直上升，最终稳定在100%的位置不再回落。

这种情况在流量高峰时段偶尔会出现，但这次发生在凌晨低峰期就显得极不正常。通过SHOW PROCESSLIST命令查看，发现有大量Sleep状态的连接堆积，更奇怪的是这些连接都来自同一个应用服务节点。这让我立即意识到：这不是简单的流量激增问题，而是典型的连接泄漏。

2. 连接池泄漏的排查思路

2.1 连接泄漏的特征识别

正常的连接池使用应该呈现锯齿状波动曲线：请求到来时获取连接，完成业务后立即释放。而泄漏场景下，连接被获取后就像破洞的水桶一样不断流失，最终导致资源耗尽。通过以下特征可以快速判断泄漏类型：

递增型泄漏：连接数随时间持续线性增长，常见于未关闭连接的情况
阶梯型泄漏：连接数在特定操作后永久增加，常见于事务未提交/回滚
节点特异性泄漏：仅部分应用节点出现泄漏，指向特定实例的代码问题

2.2 关键诊断命令

sql复制-- 查看当前连接详情
SHOW FULL PROCESSLIST;

-- 统计各状态连接数
SELECT COMMAND, COUNT(*) 
FROM information_schema.PROCESSLIST 
GROUP BY COMMAND;

-- 检查最大连接数配置
SHOW VARIABLES LIKE 'max_connections';

-- 查看连接存活时间（单位：秒）
SELECT TIME, COUNT(*) 
FROM (
  SELECT TIMESTAMPDIFF(SECOND, TIME, NOW()) AS TIME 
  FROM information_schema.PROCESSLIST
) t 
GROUP BY TIME;

3. 深度排查实战记录

3.1 连接来源定位

通过审计日志发现，异常连接都指向订单服务的某个实例。进一步检查该节点的线程堆栈，发现大量连接被OrderQueryService的查询方法持有。以下是关键的排查步骤：

使用Arthas监控JDBC连接获取/释放情况：

bash复制watch com.zaxxer.hikari.HikariDataSource getConnection '{params,returnObj}'
watch com.mysql.jdbc.ConnectionImpl close '{params,returnObj,throwExp}'

发现存在大量连接获取后没有触发close调用
通过BTrace追踪连接生命周期：

java复制@OnMethod(clazz="com.mysql.jdbc.ConnectionImpl", method="close")
public static void traceClose() {
    println(strcat("Connection closed at: ", timeMillis()));
}

3.2 根本原因分析

最终定位到一段使用MyBatis的代码：

java复制@Transactional
public List<Order> queryOrders(Long userId) {
    SqlSession session = sqlSessionFactory.openSession();
    try {
        return session.selectList("queryOrders", userId);
    } finally {
        // 致命错误：在@Transactional方法内又创建了独立Session
        session.close(); 
    }
}

这里存在两个严重问题：

方法已有@Transactional注解，会自动管理连接
内部又手动创建SqlSession导致连接管理冲突
finally中的close在事务提交前执行，实际未释放连接

4. 解决方案与优化措施

4.1 紧急恢复方案

临时调整连接池配置（需评估业务量）：

properties复制# HikariCP配置
spring.datasource.hikari.maximum-pool-size=200 → 300
spring.datasource.hikari.leak-detection-threshold=60000

对问题节点实施优雅重启：

bash复制# 保留现有连接处理完请求
kill -15 <pid>

设置连接自动回收：

sql复制SET GLOBAL wait_timeout = 300;
SET GLOBAL interactive_timeout = 300;

4.2 长期修复方案

代码层修复：

java复制public List<Order> queryOrders(Long userId) {
    // 移除手动session管理
    return orderMapper.queryOrders(userId);
}

增加连接池监控：

java复制@Bean
public HikariPoolMXBean hikariPoolMXBean() {
    return hikariDataSource.getHikariPoolMXBean();
}

配置防御性参数：

properties复制spring.datasource.hikari.max-lifetime=1800000
spring.datasource.hikari.idle-timeout=600000
spring.datasource.hikari.connection-timeout=30000

5. 防护体系升级

5.1 监控告警配置

Prometheus监控规则示例：

yaml复制- alert: MySQLConnectionPoolCritical
  expr: avg_over_time(mysql_global_status_threads_connected[1m]) / mysql_global_variables_max_connections > 0.8
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "MySQL连接池使用率超过80%"

Grafana监控看板关键指标：

连接池使用率
连接获取等待时间
连接存活时间分布
按应用分组的连接数

5.2 压测验证方案

使用JMeter模拟以下场景：

xml复制<ThreadGroup>
  <LoopController loops="1000" />
  <JDBCDataSource configElement="MySQLPool"/>
  <JDBCRequest queryType="Select" query="SELECT sleep(1)"/>
</ThreadGroup>

验证指标：

连接数是否稳定在池大小范围内
是否存在未关闭的连接
长时间运行后的内存增长情况

6. 经验总结与避坑指南

事务注解的隐藏陷阱：

避免在@Transactional方法内嵌套手动连接管理
注意不同传播机制对连接获取的影响
推荐使用声明式事务而非编程式事务

连接池配置黄金法则：

properties复制# 计算公式
最大连接数 = (核心数 * 2) + 有效磁盘数

# 推荐配置
spring.datasource.hikari.maximum-pool-size=10
spring.datasource.hikari.minimum-idle=5

必须实现的监控项：

连接获取等待时间 > 100ms需告警
连接存活时间 > max-lifetime的80%需检查
空闲连接数持续为0需扩容

连接泄漏检测技巧：

java复制// 在启动时添加泄漏检测
HikariConfig config = new HikariConfig();
config.setLeakDetectionThreshold(30000);

这次事故让我深刻体会到，数据库连接就像酒店房间钥匙——每次使用后必须及时归还前台，否则很快就会无房可住。现在我们在CI流程中增加了连接泄漏检测环节，任何修改数据库访问的代码都必须通过以下测试：

java复制@Test
public void testConnectionLeak() throws Exception {
    for (int i = 0; i < 100; i++) {
        yourMethodUnderTest();
        assertThat(dataSource.getHikariPoolMXBean().getActiveConnections())
            .isLessThan(5);
    }
}