连接数爆满：max_connections 与连接池

直接给答案：Too many connections 出现时，先别把 max_connections 一味调大——每个连接都占内存，盲目放大可能把数据库压垮。正确做法是先查连接从哪来，再把应用侧池化做对。 ## 问：第一步先看什么 ``` SHOW PROCESSLIST; SHOW STATUS LIKE 'Threads_connected'; ``` processlist 重点看 user 和 host 两列。大量连接来自同一台应用机、状态长时间是 Sleep，说明应用在堆空闲连接或没释放；来源不明的 IP 则要查有没有人蹭库。再看 command 列：Query 状态多，说明连接在等执行结果；Sleep 状态多，说明在攒空闲连接。两种现象的处理方向完全不同。 ## 问：常见原因有哪些 一是应用没做连接池，每个请求新建连接，高并发瞬间打满；二是异常路径没关闭连接，泄漏慢慢累积；三是慢查询把连接长期占住，新连接排队进不来；四是配置本身就低，业务涨上来后不够用。四种原因对应四种解法，调大参数只对其中一种有效。 ## 问：应用侧怎么池化 Java 项目常用 HikariCP 连接池，核心三项：maximumPoolSize 一般给 10 到 20，够用就好；connectionTimeout 是获取连接的等待上限，别设成无限等；maxLifetime 要小于 MySQL 的 wait_timeout，避免用到已被服务端掐断的连接。PHP 传统模式无常驻进程，用持久连接要配合控制 FPM 的进程数，防止连接越堆越多。池子也不是越大越好，超过数据库的处理能力，排队只是从池内挪到库内，总吞吐反而下降。 ## 问：max_connections 设多少合适 每个连接占几百 KB 到几 MB 内存，专机 8G 内存给到 500 上下是常见量级，混部机器更保守： ``` SET GLOBAL max_connections = 500; ``` 同时把 wait_timeout 从默认八小时调短到几分钟，空闲连接早释放，给有效连接腾位置。调整后观察一天 Threads_connected 曲线，长期贴着上限就继续排查占用，稳定在两成以下说明配得富余。 ## 问：以后怎么防 监控 Threads_connected，到上限八成就告警；发布前压测一轮连接行为；慢查询治理跟上，连接占得久多半因为 SQL 慢。压测报告里把连接峰值记下来，容量规划按这个数乘安全系数。 连接数是资源，不是数字游戏。池化做对之后会发现，所谓连接不够，多数时候是连接被浪费了。