MySQL 连接数打满的三种成因与调参顺序

"Too many connections" 出现时，第一反应往往是调大 max_connections，但多数情况下那只是把问题推迟了半小时。

先看是谁在占连接

SHOW PROCESSLIST;
SELECT user, host, count(*) FROM information_schema.processlist GROUP BY user, host ORDER BY 3 DESC;

如果某个账号占了八成连接且状态多为 Sleep，问题基本确定：应用侧连接池没释放，或者 wait_timeout 太长让空闲连接一直挂着。

三种典型成因

• 连接泄漏。代码里开了连接没关，尤其在异常分支。特征是连接数只涨不跌，重启应用立刻恢复。
• 慢查询堆积。单条 SQL 跑几十秒，请求排队把连接池占满。这类要看 SHOW PROCESSLIST 里的 Time 列。
• 连接池配置不当。应用侧最大连接数 × 应用实例数超过数据库上限，高峰必然爆。

调参的正确顺序

第一步永远是修泄漏和慢查询，第二步才是调参数。真要调，按这个顺序：先把 wait_timeout 从默认 8 小时降到 300 秒以内，空闲连接会自动回收；再看 max_connections 与内存的关系，每连接大约占 1-2MB，4G 内存的机器给 300-500 比较合理，给到 2000 只会让内存先崩；最后确认 thread_cache_size 足够，避免连接频繁创建销毁。

兜底手段

给应用账号单独设 max_user_connections，防止一个业务把整库拖死；同时留一个管理账号不限额，出问题时还能连进去处理。这个细节在真出事的那天非常关键。

本文首发于 izzsj.com，作者保留全部权利。未经书面授权，禁止任何形式采集、转载与镜像；转载请注明来源并保留原文链接。