MySQL 连接池耗尽怎样从线程状态定位

MySQL 报 Too many connections 时，连接池“拿不到连接”不等于数据库一定需要立刻把 max_connections 调大。先把问题拆成三个方向：连接是否长期不释放、已有连接是否被慢 SQL 或锁等待占住、还是流量在短时间内冲过了池和服务端的共同上限。

官方文档地址：https://dev.mysql.com/doc/refman/8.4/en/too-many-connections.html

最有区分度的证据是“当前连接数与上限的距离 + Threads_running 的占比 + 线程状态是否持续不降”。连接多但大多 Sleep，优先查释放链路；运行线程多且状态停留很久，优先查慢 SQL、锁和事务；峰值过后迅速恢复，才更像瞬时并发。

先比较上限、当前连接数和历史峰值

第一轮只读全局状态，不需要结束任何会话。Threads_connected 表示当前打开的连接，Threads_running 表示没有处于睡眠状态的线程，Max_used_connections 是服务器启动以来的同时连接峰值；Connection_errors_max_connections 则能提示是否出现过撞上限的拒绝。

-- 先把连接上限、当前数量和历史峰值放在同一轮采样中
SHOW GLOBAL VARIABLES LIKE 'max_connections';
SHOW GLOBAL STATUS WHERE Variable_name IN (
  'Threads_connected',
  'Threads_running',
  'Max_used_connections',
  'Connection_errors_max_connections'
);

-- 记录采样时间，便于和应用连接池等待日志对齐
SELECT NOW() AS sampled_at;

如果 Threads_connected 长时间贴近 max_connections，同时 Connection_errors_max_connections 继续增加，才可以确认服务端连接上限正在影响新连接。Max_used_connections 只是历史峰值，不能单独说明当前仍然拥堵；相反，当前连接数已经回落但连接池仍报超时，就要把数据库采样和应用池的最大连接数、等待队列一起对照。

从 SHOW FULL PROCESSLIST 看连接到底卡在哪里

确认连接数异常后，再看会话本身。SHOW FULL PROCESSLIST 比普通形式保留更完整的语句文本；其中 Command、Time、State 和 Info 需要放在一起解释，不能只凭一条状态名称杀连接。

-- FULL 用于保留完整语句文本；生产环境先确认账号具备查看权限
SHOW FULL PROCESSLIST;

-- 按当前状态筛出排查重点，但不改变任何会话
SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO
FROM information_schema.PROCESSLIST
WHERE COMMAND  'Sleep'
ORDER BY TIME DESC;

没有 PROCESS 权限时，账号通常只能看到自己的线程；这会让“连接数很高但列表很少”看起来像矛盾。排查账号应使用最小必要的管理权限，并注意 Info 可能包含业务参数，日志留存时不要直接扩散敏感内容。

用 Performance Schema 汇总线程来源和状态

当列表行数很多时，逐条阅读不如先按来源聚合。MySQL 8.4 的 performance_schema.threads 同时提供前台连接的 PROCESSLIST_ID、账号、主机、命令和状态；下面的查询只保留客户端前台线程，并把空状态归为“未提供状态”。

-- 按账号、来源主机和线程状态汇总当前前台连接
SELECT
  PROCESSLIST_USER AS user_name,
  PROCESSLIST_HOST AS client_host,
  COALESCE(PROCESSLIST_COMMAND, '未提供命令') AS command_name,
  COALESCE(PROCESSLIST_STATE, '未提供状态') AS thread_state,
  COUNT(*) AS connection_count
FROM performance_schema.threads
WHERE TYPE = 'FOREGROUND'
  AND PROCESSLIST_ID IS NOT NULL
GROUP BY PROCESSLIST_USER, PROCESSLIST_HOST,
         PROCESSLIST_COMMAND, PROCESSLIST_STATE
ORDER BY connection_count DESC;

如果某个应用主机的 Sleep 连接不断累积，而其他主机正常，根因范围会从“整个 MySQL 容量不足”收窄到该实例的连接归还、连接池生命周期或网络断开处理。若多个来源的非睡眠线程都集中在相同等待状态，再去看具体语句、锁和事务；不要把聚合结果当作单条 SQL 的执行证据。

按证据区分连接泄漏、慢查询和并发峰值

可以用连续采样形成一个简单判断表：

• 连接未释放：Threads_connected 接近上限，Threads_running 却不高，列表中大量同一来源的 Sleep，并且连接数在低流量时也不回落。先查应用是否在所有异常分支归还连接，再处理池的空闲和生命周期参数。
• 慢查询或锁等待：Threads_running 持续高，非睡眠线程的 Time 和 State 长时间不变。此时扩大连接上限可能只会让更多请求进入数据库，应该先看语句、索引、事务和锁等待。
• 瞬时并发峰值：连接数和运行线程在流量尖峰同步升高，尖峰后明显回落，拒绝计数只在同一时间段增加。此时要把应用池上限、请求排队、超时和数据库承载能力作为一个容量问题处理。

修复后至少再采样几轮：连接数是否回落、运行线程是否恢复到常态、拒绝计数是否停止增长，以及同一来源的异常状态是否消失。只有这些趋势和应用池等待同时改善，才说明处理动作命中了根因。直接把 max_connections 调得很大，可能把内存和调度压力向后推迟，却没有修复连接泄漏或慢 SQL。

常见追问

Threads_connected 很高但 Threads_running 很低，是不是数据库空闲？

不一定。它说明很多连接当前没有执行语句，但仍然占着连接配额。若这些连接长期来自同一应用实例，先检查池是否按请求归还、空闲超时是否失效。

看到大量 Sleep 可以直接执行 KILL 吗？

不要把批量 KILL 当成默认修复。先确认来源、业务影响和事务状态，保留管理连接；临时释放连接后仍要修复应用侧归还逻辑，否则问题会再次出现。

为什么调大 max_connections 后连接池仍然超时？

连接池可能有更小的自身上限，或者连接已经被慢查询、锁等待和未提交事务占住。应同时看应用池等待、Threads_running 和进程列表状态，不能只比较服务端变量。

这类故障的关键不是记住某个阈值，而是把“连接总量”和“连接正在做什么”分开看。先用状态变量确认是否撞上限，再用进程列表和线程聚合确定来源与状态，最后依据连续趋势选择修复动作，才不会把连接泄漏误判成容量不足。