**📌今日关键词：MySQL连接数、Too many connections、连接泄漏、max_connections、紧急排查**

---

大家好，我是数据库小学妹 👋

上周五我正准备收拾东西下班，监控群突然炸了——"数据库连不上了！所有接口都在报错！"一看应用日志，满屏都是 `Too many connections`。

说真的，那一瞬间心跳直接飙到120。

之前我们聊过连接池怎么设计才能预防这种问题，但预防归预防，真出了事怎么办？连接数爆满是生产环境里最常见的紧急故障之一，处理不好就是全线业务停摆。

今天把我的排查和处理过程整理出来，从"先活下来"到"搞清楚为什么"，希望大家在遇到同类问题时，能少走弯路少踩坑，从容应对！

---

## 一、Too many connections 的本质

先搞清楚这个报错的本质。

MySQL 有个参数 `max_connections`，限制了同时能连多少个客户端。5.7和8.0默认是151个。当已建立的连接数达到这个上限，新的连接请求就会被拒绝，报 `ERROR 1040 (HY000): Too many connections`。

注意一个细节：root用户在本地通过socket连接时，MySQL会预留一个额外的连接位。所以业务连不上了，DBA用root还是能登进去排查。这个设计就是给紧急情况留的后门。

连接数打满不等于数据库挂了。进程还在，数据也没丢，就是"门关了进不去"。搞清楚这一点，心态就稳了。

---

## 二、紧急评估：30秒内搞清楚状况

收到告警先别慌，三步快速判断局势。

### 第一步：MySQL 还活着吗

```bash
# 看进程
ps aux | mysqld | grep -v grep

# 看端口
ss -tlnp | grep 3306

# 看机器负载
uptime
```

进程在、端口在、负载没爆，说明MySQL本身没挂，就是连接满了。这算好消息。

### 第二步：连了多少，连的谁

```bash
# 用socket直连，不走TCP
mysql -u root -p -S /var/lib/mysql/mysql.sock -e "SHOW PROCESSLIST;" 2>/dev/null | wc -l
```

如果连socket都连不上（很少见），从操作系统层看：

```bash
# 看3306端口的连接总数
ss -ant | grep :3306 | wc -l

# 看每个IP的连接分布
ss -ant | grep :3306 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn
```

### 第三步：区分两种关键指标

```sql
SHOW STATUS LIKE 'Threads_connected';
SHOW STATUS LIKE 'Threads_running';
SHOW VARIABLES LIKE 'max_connections';
```

`Threads_connected` 是已建立的连接总数，包含睡觉的。`Threads_running` 是正在跑SQL的连接数。

这两个数的区别很关键。如果 `Threads_connected` 高但 `Threads_running` 低，说明大量连接在Sleep，杀了就行。如果 `Threads_running` 也高，说明有东西在跑慢查询，得找到它干掉。

---

## 三、快速止血：先让业务活过来

确认了情况，开始止血。以下操作有侵入性，执行前心里要有数。

### 杀掉睡眠连接

大多数情况下，连接数爆满的元凶是大量Sleep连接。这些连接建立后啥也没干，或者干完了没关，白白占着坑位。

```sql
-- 杀掉超过30秒的睡眠连接
SELECT CONCAT('KILL ', ID, ';')
FROM INFORMATION_SCHEMA.PROCESSLIST
WHERE COMMAND = 'Sleep'
AND TIME > 30;
```

拿到结果后复制出来执行。或者更暴力一点：

```bash
# 一行搞定
mysql -u root -S /var/lib/mysql/mysql.sock -N -e "
SELECT CONCAT('KILL ', ID, ';')
FROM INFORMATION_SCHEMA.PROCESSLIST
WHERE COMMAND = 'Sleep' AND TIME > 30;
" | mysql -u root -S /var/lib/mysql/mysql.sock
```

我第一次处理这个问题的时候，把所有Sleep连接都杀了，包括一些正常的。后来才知道要加 `TIME > 30` 的条件，刚建立几秒的Sleep连接可能是正常的——应用从连接池取出来准备用，还没来得及发SQL。

### 临时提高 max_connections

清理完还不够？把上限临时拉高：

```sql
-- 动态调整，不用重启
SET GLOBAL max_connections = 500;
```

这个改法MySQL重启就失效了。想持久化的话用 `SET PERSIST`（8.0+）或者改my.cnf。但记住，这只是应急，不是解法。max_connections设太大，内存扛不住反而更惨。

### 杀掉慢查询

如果 `Threads_running` 很高，得找到那些跑得最久的查询：

```sql
SELECT
    ID,
    USER,
    HOST,
    DB,
    COMMAND,
    TIME,
    STATE,
    LEFT(INFO, 100) AS QUERY
FROM INFORMATION_SCHEMA.PROCESSLIST
WHERE COMMAND != 'Sleep'
ORDER BY TIME DESC
LIMIT 10;
```

看到执行了300秒的查询？大概率就是它在捣乱。确认不影响业务后干掉：

```sql
KILL <ID>;
```

注意区分：`KILL` 杀的是连接，`KILL QUERY` 只停查询不断连接。紧急情况下直接 `KILL` 更彻底。

---

## 四、根因分析：四个方向挨个查

血止住了，得搞清楚为什么会爆。连接数爆满不是病根，是症状。常见根因就四个。

### 根因一：慢查询堆积

这是最常见的原因。一条SQL执行30秒，这30秒内这个连接一直在干活，别的请求只能开新连接。如果慢查询持续涌入，连接数很快打满。

排查方法：

```sql
-- 通过performance_schema看哪些SQL最耗时
SELECT
    DIGEST,
    COUNT_STAR,
    SUM_TIMER_WAIT / 1000000000000 AS SUM_SECONDS,
    AVG_TIMER_WAIT / 1000000000000 AS AVG_SECONDS,
    LEFT(SQL_TEXT, 200) AS SQL_SAMPLE
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 10;
```

再看慢查询日志确认：

```bash
tail -100 /var/log/mysql/slow.log | grep -i "Query_time"
```

我遇到过一次，财务模块导出报表触发了一条跨五张表的JOIN查询，没走索引，单次执行3分钟。当天下午正好好几个财务在同时导出，连接直接打满。后来加了索引，执行时间从3分钟降到0.2秒，问题解决。

### 根因二：连接泄漏

这个最隐蔽。应用代码拿到连接后没关闭，连接一直占着不释放。少量泄漏看不出来，积累几天就爆了。

怎么判断是不是泄漏：

```sql
SELECT
    USER,
    HOST,
    COUNT(*) AS CONN_COUNT,
    MAX(TIME) AS MAX_TIME,
    MIN(TIME) AS MIN_TIME
FROM INFORMATION_SCHEMA.PROCESSLIST
WHERE COMMAND = 'Sleep'
GROUP BY USER, HOST
HAVING COUNT(*) > 10
ORDER BY CONN_COUNT DESC;
```

某个来源IP的Sleep连接数持续增长，而且 `MAX_TIME` 特别大（比如几千秒），基本就是泄漏了。

我之前见过的一个案例：Java应用的异常处理分支里，catch块只记了日志，没关连接。正常请求没问题，一碰到异常就漏一个。平时流量小看不出来，攒了一周，周五下午高峰时爆了。

修复代码很简单，用 `try-with-resources`：

```java
// 泄漏写法
public void queryData() {
    Connection conn = dataSource.getConnection();
    // 异常时conn不会被关闭
    query(conn);
}

// 正确写法
public void queryData() {
    try (Connection conn = dataSource.getConnection()) {
        query(conn);
    }
}
// 方法结束自动关闭，异常也会关
```

### 根因三：短连接冲击

PHP和部分Python应用默认用短连接——每次请求新建连接，用完就关。并发量一上来，MySQL要不停地做TCP握手、认证、分配线程，忙不过来连接就堆上了。

```sql
-- 看连接建立速率
SHOW STATUS LIKE 'Connections';
SHOW STATUS LIKE 'Aborted_connects';
```

`Aborted_connects` 持续涨，说明大量连接建立失败。结合 `wait_timeout` 的设置看：

```sql
SHOW VARIABLES LIKE 'wait_timeout';
SHOW VARIABLES LIKE 'interactive_timeout';
```

这两个值如果设得很短（比如60秒），Sleep连接60秒就断，应用下次请求又得新建。频繁建连关连，MySQL压力山大。

一般建议 `wait_timeout = 600`（10分钟），别太短也别太长。

### 根因四：max_connections 确实太小

MySQL默认151，中等流量的生产环境根本不够用。

```sql
SHOW VARIABLES LIKE 'max_connections';
SHOW STATUS LIKE 'Max_used_connections';
```

`Max_used_connections` 是MySQL启动以来的历史峰值。如果这个值已经很接近 `max_connections`，说明上限确实该调了。

但别拍脑袋调，得算。每个连接占大约2-4MB内存（thread_stack + 各种buffer），服务器能撑多少连接取决于还剩多少内存：

```
可分配连接数 ≈ (总内存 - Buffer Pool - 系统预留) / 单连接内存
```

典型经验值：

| 服务器配置 | max_connections 建议 |
| --- | --- |
| 4核8G | 300~500 |
| 8核16G | 500~800 |
| 16核32G | 800~1500 |

调完记得观察一段时间，别调完就走。

---

## 五、一个诊断脚本搞定排查

上面的信息量不小，紧急情况下手忙脚乱容易漏。我写了一个脚本，一键收集所有关键信息：

```bash
#!/bin/bash
# mysql_conn_diagnosis.sh
# 用法：bash mysql_conn_diagnosis.sh

SOCKET="/var/lib/mysql/mysql.sock"
OUTPUT="/tmp/mysql_conn_diag_$(date +%Y%m%d_%H%M%S).txt"

exec > >(tee "$OUTPUT") 2>&1

echo "====== MySQL 连接数爆满诊断 ======"
echo "时间: $(date)"
echo ""

echo "--- 1. 连接数概览 ---"
mysql -u root -S "$SOCKET" -N -e "
SELECT 'Threads_connected:', VARIABLE_VALUE FROM performance_schema.global_status WHERE variable_name='Threads_connected';
SELECT 'Threads_running:', VARIABLE_VALUE FROM performance_schema.global_status WHERE variable_name='Threads_running';
SELECT 'max_connections:', @@max_connections;
SELECT 'Max_used_connections:', VARIABLE_VALUE FROM performance_schema.global_status WHERE variable_name='Max_used_connections';
" 2>/dev/null

echo ""
echo "--- 2. 连接来源分布 ---"
mysql -u root -S "$SOCKET" -e "
SELECT USER, SUBSTRING_INDEX(HOST,':',1) AS SRC_IP, COUNT(*) AS CNT
FROM INFORMATION_SCHEMA.PROCESSLIST
GROUP BY USER, SRC_IP
ORDER BY CNT DESC LIMIT 10;
" 2>/dev/null

echo ""
echo "--- 3. 执行时间最长的查询 ---"
mysql -u root -S "$SOCKET" -e "
SELECT ID, USER, TIME, STATE, LEFT(INFO,120) AS QUERY
FROM INFORMATION_SCHEMA.PROCESSLIST
WHERE COMMAND != 'Sleep'
ORDER BY TIME DESC LIMIT 10;
" 2>/dev/null

echo ""
echo "--- 4. 未提交事务 ---"
mysql -u root -S "$SOCKET" -e "
SELECT trx_id, trx_state, trx_started,
       TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS RUNNING_SEC,
       LEFT(trx_query, 100) AS QUERY
FROM INFORMATION_SCHEMA.INNODB_TRX
ORDER BY trx_started LIMIT 10;
" 2>/dev/null

echo ""
echo "--- 5. 锁等待 ---"
mysql -u root -S "$SOCKET" -e "
SELECT COUNT(*) AS lock_wait_cnt FROM INFORMATION_SCHEMA.INNODB_TRX WHERE trx_state='LOCK WAIT';
" 2>/dev/null

echo ""
echo "诊断完成，结果已保存到 $OUTPUT"
```

把这个脚本提前放在服务器上，出事的时候直接跑，不用现场想命令。

---

## 六、监控告警：别等爆了才知道

连接数爆满的可怕在于——等你发现的时候业务已经挂了。必须靠监控提前预警。

### Prometheus + MySQL Exporter

用 `mysqld_exporter` 采集MySQL指标，核心关注这几个：

```
# 连接使用率
mysql_global_status_threads_connected / mysql_global_variables_max_connections

# 活跃线程数
mysql_global_status_threads_running

# 连接拒绝速率
rate(mysql_global_status_connection_errors_total[5m])
```

### 告警规则

```yaml
# mysql_connection_alerts.yml
groups:
  - name: MySQL连接数告警
    rules:
      - alert: MySQLConnectionsHigh
        expr: mysql_global_status_threads_connected / mysql_global_variables_max_connections > 0.8
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "MySQL连接数超过80%"

      - alert: MySQLConnectionsCritical
        expr: mysql_global_status_threads_connected / mysql_global_variables_max_connections > 0.95
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "MySQL连接数即将打满，立即处理！"

      - alert: MySQLThreadsRunningHigh
        expr: mysql_global_status_threads_running > 20
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "MySQL活跃连接数过高，可能存在慢查询"
```

80%告警、95%严重——给处理留出缓冲时间。别设到99%才叫，那时候已经来不及了。

### 业务级心跳

光看连接数还不够。我习惯在Grafana面板上同时放三个指标：连接数趋势、活跃线程数、慢查询速率。三个一起看，才能判断是"连接没关"还是"SQL跑得慢"。

---

## 七、长期方案：参数 + 连接池 + 代码

止血和定位解决的是当下，长期不出问题得从三个层面做。

### 参数调优

```sql
-- 按服务器配置设合理的上限
SET PERSIST max_connections = 800;

-- 睡眠连接别占太久
SET PERSIST wait_timeout = 600;
SET PERSIST interactive_timeout = 600;
```

8.0的 `SET PERSIST` 很方便，改完立即生效且重启不丢。比改my.cnf安全。

### 上连接池

连接泄漏和短连接问题的根本解法是上连接池。Java用HikariCP：

```yaml
spring:
  datasource:
    hikari:
      maximum-pool-size: 20
      minimum-idle: 5
      connection-timeout: 30000
      idle-timeout: 600000
      max-lifetime: 1800000
```

`maximum-pool-size` 的经验值是 `(CPU核数 * 2) + 磁盘数`。8核机器配20左右差不多。别设太大，连接池太大会适得其反。

Python用内置的连接池：

```python
from mysql.connector import pooling

pool = pooling.MySQLConnectionPool(
    pool_name="app_pool",
    pool_size=10,
    host="localhost",
    database="mydb",
    user="app_user",
    password="xxx"
)

def query(sql, params=None):
    conn = pool.get_connection()
    try:
        cursor = conn.cursor(dictionary=True)
        cursor.execute(sql, params or ())
        return cursor.fetchall()
    finally:
        cursor.close()
        conn.close()  # 归还到池，不是真断开
```

### ProxySQL 做连接复用

如果应用代码改不动（老系统），可以在数据库前面放ProxySQL做连接复用：

```sql
-- ProxySQL管理端
mysql -h 127.0.0.1 -P 6032 -u admin -padmin

-- 查看连接池状态
SELECT * FROM stats_mysql_connection_pool;

-- 调整后端连接上限
UPDATE mysql_servers SET max_connections=100 WHERE hostgroup_id=10;
LOAD MYSQL SERVERS TO RUNTIME;
```

ProxySQL能扛住几千个前端连接，后端只开几十个到MySQL，相当于一个连接"漏斗"。

---

## 八、五个真实场景速查

| 场景 | 特征 | 处理 |
| --- | --- | --- |
| 促销突发流量 | 连接数几分钟内飙升 | 临时调高max_connections + 杀Sleep连接 + 事后上连接池 |
| 慢查询堆积 | Threads_running高，有长时间执行的SQL | 找到慢SQL杀掉 + 加索引优化 |
| 连接泄漏 | Sleep连接数持续增长，MAX_TIME很大 | 修复代码 + 定时清理脚本兜底 |
| max_connections太小 | Max_used_connections接近上限 | 算好内存后调大上限 |
| ProxySQL自身瓶颈 | 通过ProxySQL连不上但直连正常 | 调整ProxySQL的pool_size和max_connections |

---

## 九、面试怎么答

**面试官：MySQL报Too many connections，你的处理流程是什么？**

> 先止血再定因。第一步确认MySQL进程还活着，用root通过socket连接（root有预留连接位）。第二步杀掉超过30秒的Sleep连接释放连接位，临时调高max_connections让业务先恢复。第三步分析根因——看Threads_running判断有没有慢查询，看Sleep连接的来源IP和TIME判断有没有连接泄漏，看Max_used_connections判断上限是不是太小。第四步针对根因做修复：慢查询加索引，泄漏修代码，上限不够就按内存算一个合理值。最后配监控告警，80%预警95%严重，别等爆了才知道。

**面试官：max_connections设多大合适？**

> 不能拍脑袋，得算。每个MySQL连接约占2-4MB内存（thread_stack加各种buffer），用总内存减去Buffer Pool和系统预留，剩下的除以单连接占用，再留一半余量。8核16G的机器一般500到800。设太大也不行，连接太多CPU和锁争用会很严重，反而比连接不够还惨。

**面试官：怎么判断是连接泄漏？**

> 看Sleep连接的来源分布。同一个IP的Sleep连接数持续增长，而且连接存活时间很长（几千秒），基本就是泄漏。正常应用的连接用完就归还，Sleep时间不会太长。泄漏的典型原因是代码里拿到连接后没在finally里关闭，异常分支更容易漏。处理方案是上连接池加try-with-resources，再配合定时清理脚本做兜底。

---

## 避坑清单

| 序号 | 坑点 | 后果 | 正确做法 |
| --- | --- | --- | --- |
| 1 | 根本不开监控，等业务报障才发现 | 业务已中断几分钟甚至几十分钟 | 配Prometheus告警，80%就预警 |
| 2 | max_connections盲目设到10000 | 内存爆了，CPU锁争用飙升，比连不上更惨 | 按内存算，留余量 |
| 3 | 杀Sleep连接不加时间条件 | 把正在等下一个请求的正常连接也杀了 | 加 TIME > 30 过滤 |
| 4 | 只止血不查根因 | 同样的问题反复发生 | 止血后必须分析是慢查询、泄漏还是配置问题 |
| 5 | 连接池size设太大 | 数据库压力反而更大，排队更严重 | 经验值：(CPU核数×2)+磁盘数 |
| 6 | wait_timeout设太短（比如30秒） | 连接频繁断开重建，MySQL握手开销大 | 一般600秒起步 |
| 7 | 应用代码不关连接，指望MySQL回收 | 连接泄漏积累到爆 | try-with-resources或finally关闭 |
| 8 | 改了max_connections不改my.cnf或不用SET PERSIST | MySQL重启后配置丢失 | 用SET PERSIST或改配置文件 |
| 9 | 出了事才想加监控 | 黄花菜都凉了 | 监控先行，上线前就配好 |
| 10 | 把连接数高等同于数据库挂了 | 盲目重启MySQL，可能丢数据 | 连接满不等于数据库挂，root能连就能救 |

---

## 总结

连接数爆满是"症状"不是"病根"。处理思路很简单：

止血 → 杀Sleep连接，临时调高max_connections

定因 → 慢查询？泄漏？短连接？上限太小？

治本 → 该加索引加索引，该修代码修代码，该上连接池上连接池

预防 → 监控告警先行，别等爆了才反应

记住一个优先级：先活下来，再查原因，最后治本。三个步骤都不能少，少了最后一步，同样的问题下周还会来。

---
我是数据库小学妹，咱们下篇见 👋


📌今日关键词：MySQL连接数、Too many connections、连接泄漏、max_connections、紧急排查

MySQL连接数爆满实战：四种根因定位与Prometheus监控告警配置

生产环境MySQL报Too many connections时怎么快速止血？从紧急评估、杀睡眠连接、临时调参到根因定位（慢查询、连接泄漏、短连接冲击），配合完整诊断脚本和监控告警配置，帮你系统性解决连接数爆满问题

数据库

运维

MySQL连接数爆满紧急处理指南：快速解决Toomanyconnections错误，从杀Sleep连接、临时调高max_connections到慢查询优化、连接泄漏修复全流程。包含诊断脚本、监控告警设置及长期优化方案，帮助DBA高效应对生产环境数据库连接问题。

大数据

服务器

Python

MySQL

Java

腾讯云数据库特惠，新用户首单0.5折起


2026年中大促 | AI 领航 智绘未来

腾讯云BI新客户首次购买9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

MySQL连接数爆满实战：四种根因定位与Prometheus监控告警配置-腾讯云开发者社区-腾讯云

MySQL连接数爆满实战：四种根因定位与Prometheus监控告警配置

MySQL连接数爆满实战：四种根因定位与Prometheus监控告警配置

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐