突然报“Too many connections”，连接池怎么配？
先说结论
“Too many connections”的根本原因通常不是“连接数不够”，而是连接没有被正确释放或慢查询占用连接太久。解决思路是先查原因，再求配置。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
“Too many connections”是MySQL生产环境最常见的报错之一。很多人遇到这个错误的第一反应是“调大max_connections”，但这往往只是头痛医头。今天把根本原因和正确解决方案讲清楚。
排查步骤
第一步：查看当前连接数
SHOW STATUS LIKE 'Threads_connected'; -- 当前连接数
SHOW VARIABLES LIKE 'max_connections'; -- 最大允许连接数
SHOW PROCESSLIST; -- 查看每个连接在做什么第二步：分析连接占用原因
SHOW PROCESSLIST里看到大量连接处于“Sleep”状态 → 应用端连接池配置不当，空闲连接太多。
看到大量连接在执行同一条慢SQL → 慢查询导致连接堆积。
看到大量连接来自同一个应用 → 该应用的连接池配置太大。
连接池核心参数
| 参数 | 含义 | 建议值 |
|---|---|---|
| maximumPoolSize | 最大连接数 | 核心数×2+磁盘数，通常设10-20 |
| minimumIdle | 最小空闲连接数 | 和maximumPoolSize相同（HikariCP官方建议） |
| connectionTimeout | 获取连接的超时时间 | 3-5秒 |
| maxLifetime | 连接最大存活时间 | 小于MySQL的wait_timeout |
关于maximumPoolSize，很多人设得太大。HikariCP的作者说过：“大多数应用用不上10个连接。”设太大反而会导致连接争抢和MySQL的线程切换开销。
实战经验
我在元宇宙社交App遇到过一次“Too many connections”。排查后发现：某个服务的连接池配了maximumPoolSize=50，但这个服务有10个实例，总共占用500个连接。而MySQL的max_connections才1000。这一个服务就占了一半。
解决方案：把maximumPoolSize从50降到10（实际监控发现平均只用了3个连接），并配合慢查询优化，彻底解决了问题。
总结
“Too many connections”先查原因再调配置。SHOW PROCESSLIST是核心诊断工具。连接池的maximumPoolSize不是越大越好，要根据实际使用量设置。
下一篇聊一个大数据开发经常做的事：把MySQL数据导入到Hive，有哪些方案？各有什么优缺点？
你们遇到过“Too many connections”吗？怎么解决的？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长