连接池配错了，数据库CPU飙到100%——连接风暴排查实录

大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！

连接池这东西，平时不出问题的时候你根本感觉不到它的存在。一旦出问题——应用连不上数据库了，或者数据库CPU莫名其妙飙到100%——你才会发现，这个小东西的威力有多大。

我见过最典型的一个案例：一个团队把HikariCP的maximumPoolSize从50调到了200，想着“连接多了并发就高了”。结果应用每次重启，200个连接同时涌向数据库，数据库的Threads_connected瞬间冲到上限，正常业务的连接全部被挤掉，整个系统瘫痪了五分钟。

连接池不是“越大越好”。今天把连接池与MySQL的交互彻底拆开讲清楚。

一、连接风暴：三种触发场景

场景一：应用重启后并发建连

应用启动时，连接池会按照minimumIdle配置初始化一批连接。如果minimumIdle设置得比较大（比如100），而且应用是多实例部署（比如10个Pod），那么一次发布重启，就会瞬间产生1000个连接请求涌向MySQL。

MySQL建立连接需要分配线程、初始化会话变量、验证权限。每个连接大约消耗几百微秒到几毫秒。1000个连接同时建连，MySQL的Threads_connected会瞬间飙升，CPU被连接建立操作占满，正常查询的响应时间急剧上升。

解决方案：控制minimumIdle的大小，不要设置得太高。同时，在应用启动时增加延迟初始化——先初始化少量连接，再通过后台线程逐步补充到minimumIdle。

场景二：连接池参数配置过大

maximumPoolSize设得过大，是另一个常见的连接风暴来源。很多团队觉得“连接多=并发高”，把maximumPoolSize设成200甚至500。

但MySQL的连接数是有限制的。max_connections默认是151，调大需要消耗更多内存（每个连接分配独立的排序缓冲区、JOIN缓冲区等）。如果应用连接池设了200，两个应用实例就是400个连接，直接把数据库的max_connections吃满。

解决方案：maximumPoolSize的计算公式参考：(CPU核心数 × 2) + 磁盘数。对于4核8G的MySQL实例，建议不超过20-30。多实例部署时，总连接数 = 单实例连接池大小 × 实例数，必须小于max_connections。

场景三：长事务占满连接池

连接池的每个连接在使用完毕后会归还给池子。但如果一个事务长时间不提交，这个连接就无法归还。如果长事务频繁出现，连接池中的可用连接会越来越少，最终耗尽。

此时应用会报“Connection is not available, request timed out”错误，但数据库层面看起来“连接数正常”——因为连接都被占用着，但没有活跃查询。

解决方案：设置maxLifetime（连接最大存活时间）和idleTimeout（空闲超时时间），确保长期不用的连接被回收。同时监控Threads_running和Threads_connected的比值，如果Threads_connected很高但Threads_running很低，说明大量连接处于空闲或等待状态。

二、连接泄漏：最隐蔽的连接池杀手

连接泄漏比连接风暴更隐蔽——它不会瞬间爆发，而是慢慢蚕食数据库的连接资源。

表现：应用运行几天后，连接数持续上涨，但业务量并没有增长。SHOW PROCESSLIST看到大量Sleep状态的连接，Time值很大。

根因：代码中获取了连接但没有在finally块中关闭。比如：

Connection conn = dataSource.getConnection();
// 业务逻辑
// 忘记 conn.close()

或者在使用ORM框架时，手动开启了事务但没有提交或回滚。

排查方法：

-- 查看当前连接状态分布
SELECT COMMAND, COUNT(*) FROM information_schema.processlist GROUP BY COMMAND;

-- 查看长时间Sleep的连接
SELECT * FROM information_schema.processlist 
WHERE COMMAND = 'Sleep' AND TIME > 300;

-- 对比连接数和活跃线程数
SHOW STATUS LIKE 'Threads_connected';
SHOW STATUS LIKE 'Threads_running';

如果Threads_connected远大于Threads_running，且差值持续扩大，基本可以确认存在连接泄漏。

三、HikariCP关键参数实战配置

HikariCP是目前Spring Boot默认的连接池，以下是几个核心参数的实战建议：

一个关键原则：maxLifetime必须小于MySQL的wait_timeout。MySQL默认wait_timeout是28800秒（8小时），如果maxLifetime设得比它大，连接会被MySQL主动断开，但连接池不知道，拿到这个连接执行查询时会报“Communications link failure”。

四、小结

连接池不是“配大了就好”。连接风暴的三种触发场景——应用重启并发建连、参数配置过大、长事务占满连接池——每一个都可能让数据库瞬间瘫痪。连接泄漏更隐蔽，慢慢蚕食连接资源，直到某一天突然耗尽。排查的核心方法是监控Threads_connected和Threads_running的比值，配置的核心原则是maxLifetime小于wait_timeout。

小耶在手，SQL 不愁

还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~