MySQL 连接池出现 Too many connections 时先查什么：线程缓存与最大连接数的定位顺序

线上接口突然返回 Too many connections，最容易做错的动作是立刻把 max_connections 调到一个很大的数。这个报错只说明普通客户端已经用完了允许的连接名额，真正原因可能是连接没有归还、突发并发把池子顶满，也可能只是大量短连接反复创建线程。先看当前连接、运行中线程和进程列表，再决定改连接池还是改 MySQL 参数，定位会快很多。

先用 Threads_connected 判断名额是否耗尽，再用 Threads_running 和 SHOW PROCESSLIST 区分“连接占着不干活”还是“查询真的在跑”；只有确认短连接创建成本高时，才检查 thread_cache_size。

先确认是连接名额耗尽，不要把线程缓存当成万能药

MySQL 的 max_connections 是同时允许的客户端连接上限，默认值在 MySQL 8.4 文档中为 151，实际部署值要以当前实例为准。服务端还会额外保留一个管理员连接名额，拥有 CONNECTION_ADMIN（旧版本常见的是 SUPER）权限的账号可以在普通连接耗尽时进入排查。

这个保留名额是应急通道，不是应用可以依赖的容量。先用管理员账号执行以下查询，把结果记下来：

SHOW VARIABLES LIKE 'max_connections';
SHOW STATUS LIKE 'Threads_connected';
SHOW STATUS LIKE 'Threads_running';
SHOW STATUS LIKE 'Threads_cached';

判断时不要只看单个瞬时值。连续采样几次更可靠：如果 Threads_connected 一直贴着 max_connections，但 Threads_running 只有个位数，问题更像是大量睡眠连接占位；如果两者同时升高，才有必要把执行中的查询作为第一嫌疑。

用 SHOW PROCESSLIST 分开空闲连接和正在执行的查询

Threads_connected 只告诉你连接数量，不告诉你每个连接为什么还在。管理员通道可执行：

SHOW FULL PROCESSLIST;

重点看 Command、Time、State 和 Info。大量 Sleep 且持续时间很长，常见原因是应用连接池上限失控、事务结束后连接未归还，或连接的空闲超时设置与业务请求寿命不匹配。大量 Query、Waiting for 或执行时间不断增长，则要继续查锁等待、慢 SQL 和下游响应，而不是先加连接。

线上不要根据一条进程列表就批量执行 KILL。先确认账号、事务状态和业务影响；误杀持有未提交事务的会话，可能让应用重试，形成更大的连接洪峰。

连接池上限要和实例容量一起算

应用通常不止一个进程，也不止一个副本。假设部署了 6 个应用实例，每个实例的连接池上限是 40，那么理论上就可能打开 240 个连接，还没有算迁移脚本、管理工具、定时任务和读写分离后的额外池子。此时 MySQL 的 max_connections=200 并不宽裕。

可先按下面的清单核对，而不是直接把数据库上限翻倍：

连接池上限应留出管理员和后台任务的余量，也要受到数据库内存、文件描述符和单连接工作内存的约束。调大 max_connections 前，至少确认操作系统的打开文件上限和实例内存能够承受；MySQL 文档也说明它的有效最大值还会受到 open_files_limit 等条件限制。

只有短连接很多时，再看 thread_cache_size

thread_cache_size 缓存的是断开后可复用的线程，不是客户端连接。连接断开后线程才可能进入缓存；新连接到来时，缓存为空才会创建新线程。因此它主要影响短连接频繁建立时的线程创建开销，不能修复连接池长期占着连接不归还的问题。

用累计状态判断它是否值得调整：

SHOW VARIABLES LIKE 'thread_cache_size';
SHOW STATUS LIKE 'Connections';
SHOW STATUS LIKE 'Threads_created';
SHOW STATUS LIKE 'Threads_cached';

如果业务连接数增长很快，Threads_created 也快速增长，而 Threads_cached 长期接近零，说明线程缓存命中不高。可以在压测或灰度窗口谨慎增加 thread_cache_size，然后观察新一段时间内 Threads_created 的增速。它不是越大越好，官方文档也指出现代线程实现下通常不会带来明显收益，除非确实存在大量新连接。

三种症状对应三种处理顺序

连接数高，运行线程低

先查连接池是否没有关闭或归还连接，再查长时间 Sleep 会话和未提交事务。修复应用生命周期后，连接数应随请求波动回落；此时单纯提高 max_connections 只会把泄漏推迟。

连接数和运行线程都高

把 SHOW FULL PROCESSLIST 与慢查询、锁等待一起看。若多个会话在等待同一张表或同一行，优先缩短事务和修正访问顺序；若是查询本身慢，先优化索引与结果集大小。

连接数不高，但 Threads_created 增长很快

这才适合检查连接建立频率、连接池复用和 thread_cache_size。调整后用同一组状态变量复查，确认线程创建增速下降，而不是只看一次 Threads_cached 的瞬时值。

常见问题：Too many connections 处理边界

把 max_connections 调到 1000 就能解决吗？

不一定。它只能增加允许的同时连接数，不能释放已经泄漏的连接，也可能放大内存和调度压力。先确认连接来源和连接池总上限。

Threads_connected 高是不是说明 SQL 很慢？

不是。它包含休眠连接；要判断是否正在执行，应同时看 Threads_running 和 SHOW FULL PROCESSLIST。

thread_cache_size 能减少 Too many connections 吗？

它主要减少线程反复创建的成本，不会减少已打开的客户端连接数量。连接名额耗尽时，先处理池大小、连接归还和长事务。

管理员保留连接可以给应用账号使用吗？

不应这样设计。它是数据库管理员在普通连接耗尽时的排障入口，应限制给管理账号，并提前验证权限和登录方式。

把排查结果变成发布前检查项

每次修改连接池或 MySQL 参数后，至少保留一轮变更前后的指标：max_connections、Threads_connected、Threads_running、Connections 和 Threads_created。如果问题来自连接泄漏，还要在应用侧增加连接借出、归还和超时的监控。这样下一次出现 Too many connections 时，可以先判断是容量、生命周期还是查询执行问题，再选择最小改动。