MySQL 连接数打满 Too many connections 怎么排查？

Question

仓乃文 · Accepted Answer

MySQL 连接数打满是线上最常见的紧急故障之一，新请求无法获取连接，业务全面报错。根本原因通常是慢查询堆积、连接泄漏或连接池配置不当。

紧急处理：
```sql
-- 1. 查看当前连接数
SHOW GLOBAL STATUS LIKE "Threads_connected";
SHOW GLOBAL STATUS LIKE "Threads_running";

-- 2. 临时调大最大连接数（不需要重启）
SET GLOBAL max_connections = 2000;

-- 3. 查看当前所有连接
SHOW PROCESSLIST;
-- 或完整版：
SELECT * FROM information_schema.processlist
ORDER BY TIME DESC;

-- 4. Kill 占用连接的慢查询
KILL <id>; -- id 是 PROCESSLIST 中的 Id
```

排查根因：
```sql
-- 1. 统计连接来源
SELECT SUBSTRING_INDEX(HOST, ":", 1) AS host, COUNT(*)
FROM information_schema.processlist
GROUP BY host ORDER BY COUNT(*) DESC;

-- 2. 找出执行时间最长的查询
SELECT ID, USER, HOST, DB, TIME, STATE, INFO
FROM information_schema.processlist
WHERE COMMAND != "Daemon"
ORDER BY TIME DESC LIMIT 20;

-- 3. 检查 Sleep 连接数
SELECT COUNT(*) FROM information_schema.processlist
WHERE COMMAND = "Sleep" AND TIME > 300;
-- 大量长时间 Sleep 连接 = 连接泄漏

-- 4. 查看慢查询日志
SHOW VARIABLES LIKE "slow_query_log%";
```

常见根因与修复：
```sql
-- 根因 1：慢查询堆积，连接排队等待
-- 修复：EXPLAIN 分析慢查询，加索引或改写 SQL

-- 根因 2：连接泄漏，应用未归还连接
-- 修复：检查连接池配置，设置超时回收
-- HikariCP: maxLifetime=1800000, idleTimeout=600000

-- 根因 3：wait_timeout 过大，Sleep 连接不释放
SET GLOBAL wait_timeout = 600;     -- 10 分钟
SET GLOBAL interactive_timeout = 600;

-- 根因 4：连接池大小超过 max_connections
-- 修复：连接池大小 = (核心数 * 2) + 有效磁盘数
-- HikariCP 默认 maximumPoolSize=10，通常够用
```

补充说明：
- Threads_running 远小于 Threads_connected 时，说明大量连接在 Sleep
- 规则：max_connections 设为业务峰值连接数的 1.5 倍，但更重要的是修复慢查询
- 连接池不是越大越好，过大反而增加 MySQL 调度开销