性能优化（执行计划 / 慢查询 / 常见陷阱） · 经典性能问题

数据库连接数打满，怎么办？应急 + 根因分析？

Database connections maxed out. What are the mitigation steps and root cause analysis?

答案语言

考察要点

这道题面试官想看你是否具备线上复杂问题的系统性排查能力。它不仅仅考察数据库知识，更考察候选人的应急响应流程、根因分析方法论以及对整个应用架构（应用层、中间件、数据库）的综合理解。高分回答需要清晰地分清“应急止血”和“根因定位”两个阶段，并能从数据库和应用两侧同时展开分析。

核心概念

理解数据库连接的全貌是解决此问题的前提。

1. 数据库连接的本质

一个数据库连接并非简单的网络 Socket，它是一个重量级资源。当客户端（如应用服务）与 MySQL 服务器建立一个连接时，服务器端会：

创建线程/进程：为该连接分配一个服务线程（thread_per_connection 模型）。
分配内存：为该线程分配独立的内存空间，用于存储会话上下文、排序缓冲区(sort_buffer_size)、连接缓冲区(join_buffer_size)等。
认证鉴权：验证用户名、密码和访问权限。
维持心跳：保持 TCP 连接的活跃状态。

因此，连接数是有限的，由核心参数 max_connections 控制。

2. 核心参数：`max_connections`

这是 MySQL 能接受的最大并发连接数。

查看当前值：SHOW VARIABLES LIKE 'max_connections';
风险：
- 设置过低：应用在高并发时会收到 "Too many connections" 错误，导致服务不可用。
- 设置过高：每个连接都消耗内存，可能导致 MySQL 服务器内存耗尽（OOM），甚至被操作系统杀掉。内存估算公式： $Total\_Memory \approx global\_buffers + (thread\_buffers \times max\_connections)$ 其中 thread_buffers 包括 sort_buffer_size, join_buffer_size, read_buffer_size 等。

3. 连接池（Connection Pool）

现代应用几乎都使用连接池（如 HikariCP, Druid, C3P0）来管理数据库连接，其核心思想是连接复用。

工作原理：应用启动时，连接池会预先创建一批连接（minIdle），当业务需要时，从池中“借用”一个连接，用完后“归还”到池中，而不是直接关闭。如果池中无可用连接，且当前连接数未达上限（maxPoolSize），则创建新连接。
关键配置：
- maxPoolSize / maximum-pool-size: 单个应用实例允许的最大连接数。
- minIdle: 最小空闲连接数。
- connectionTimeout: 获取连接的超时时间。
- idleTimeout: 连接在池中最大空闲时间，超时会被回收。

4. 连接状态

通过 SHOW PROCESSLIST; 命令可以查看当前所有连接的状态，关键 Command 字段包括：

Command	含义	常见问题
`Query`	连接正在执行查询。	大量连接处于此状态且 `Time` 较长，说明有慢查询。
`Sleep`	连接处于空闲状态，等待新的查询。	大量连接长期处于 `Sleep` 状态，是连接泄露的典型特征。
`Locked`	连接正在等待表锁或行锁。	说明存在锁竞争，可能由慢查询或不合理的事务导致。
`Connect`	连接正在建立或认证中。	大量连接处于此状态，可能表明数据库负载极高或网络有问题。

示例 SHOW PROCESSLIST 输出：

text

 1+-----+------+-----------------+------+---------+------+-----------+------------------+
 2| Id  | User | Host            | db   | Command | Time | State     | Info             |
 3+-----+------+-----------------+------+---------+------+-----------+------------------+
 4| 101 | app  | 10.0.1.10:12345 | my_db| Sleep   | 300  |           | NULL             |
 5| 102 | app  | 10.0.1.11:23456 | my_db| Query   | 50   | executing | SELECT ...       |
 6| 103 | app  | 10.0.1.10:34567 | my_db| Sleep   | 298  |           | NULL             |
 7+-----+------+-----------------+------+---------+------+-----------+------------------+

上表中，Id 为 101 和 103 的连接已空闲近 5 分钟，若大量出现，极有可能是应用 10.0.1.10 发生了连接泄露。

常见低分回答

“直接调大 max_connections 就行了。” —— 这是最典型的错误。治标不治本，盲目调大可能耗尽服务器内存，导致数据库崩溃，是极其危险的操作。
“把 Sleep 的连接都 KILL 掉。” —— 反应式而非分析式。虽然能临时释放连接，但无法解决根本问题，很快连接数会再次被打满。且可能误杀正在事务中但暂时空闲的正常连接。
“重启数据库。” —— 终极“核武器”，会导致服务中断，丢失未提交的事务。这是在所有方法都无效且业务完全卡死的最后手段，绝不能作为首选方案。
“这是 DBA 的事，应用开发管不了。” —— 暴露了候选人缺乏全局视野和主人翁意识。连接数问题大概率是应用端代码或配置不当引起的。
“把 wait_timeout 调小一点。” —— 虽然能让服务端主动踢掉空闲连接，但无法解决应用侧的连接泄露。应用侧的连接池可能仍然认为这些连接有效，尝试使用时会报错，引发新的问题。

工程实践与优化

面对此问题，应遵循“应急响应 -> 根因分析 -> 长期优化”的结构化流程。

第一阶段：应急响应（止血）

目标是在最短时间内恢复服务。

评估影响范围：确认是单个服务还是所有服务都无法连接数据库。
紧急扩容连接数（谨慎操作）：如果服务器内存尚有富余，可以临时调高 max_connections 以缓解燃眉之急，为排查争取时间。
sql
```
 1-- 检查当前最大使用连接数
 2SHOW GLOBAL STATUS LIKE 'Max_used_connections';
 3-- 临时增加100个连接（需评估内存）
 4SET GLOBAL max_connections = 600;
```
必须同时监控服务器内存使用情况，避免 OOM。
识别并终止异常连接：通过 SHOW PROCESSLIST 找到“元凶”。
- 场景A：大量长时间 Sleep 连接：说明存在连接泄露。找到来源 Host，优先重启该 Host 上的应用实例，这是最快释放连接池的办法。
- 场景B：大量长时间 Query 或 Locked 连接：说明有慢查询或锁等待。
  sql
```
 1-- 查找执行超过 60 秒的查询
 2SELECT * FROM information_schema.processlist WHERE Command = 'Query' AND Time > 60 ORDER BY Time DESC;
 3-- 找到罪魁祸首的SQL后，KILL掉其连接ID
 4KILL 102;
```
应用层降级/限流：如果数据库压力过大，可在网关或应用层对非核心业务进行降级或限流，保护核心业务。

第二阶段：根因分析（根治）

服务恢复后，必须定位根本原因，防止复发。

数据库侧分析：
- SHOW PROCESSLIST 快照：在问题发生时，多次执行 SHOW PROCESSLIST 并保存结果。分析 Host、Command、Time 的分布。如果大量连接来自少数几个应用IP，且状态为 Sleep，则问题源头直指这些应用。
- 慢查询日志（Slow Query Log）：检查是否有慢查询占用了连接过长时间。
- wait_timeout 配置：检查 wait_timeout 和 interactive_timeout 的值。wait_timeout 对应用连接池生效，默认8小时（28800秒），过长可能导致泄露的连接长时间得不到释放。可以适当调低（如10分钟），但这只是辅助手段。
  sql
```
 1SHOW GLOBAL VARIABLES LIKE '%timeout%';
```
应用侧分析：
- 连接池配置审查：这是最常见的原因。
  - maxPoolSize 设置是否合理？ 关键公式：DB 的 max_connections >= Σ (应用实例数 * 单实例 maxPoolSize)。很多时候是应用实例扩容后，总连接请求数超过了数据库上限。
  - 泄露检测配置：现代连接池（如 HikariCP, Druid）都提供连接泄露检测功能，务必开启。例如，配置一个 leakDetectionThreshold，当一个连接被借出超过阈值时间仍未归还，就会打印警告日志，帮助定位到具体代码。
- 代码审查（Code Review）：
  - 检查获取连接后，是否在 finally 块中保证了 connection.close() 的执行。这是经典的连接泄露模式。
  java
```
 1// 错误示例
 2Connection conn = null;
 3try {
 4    conn = dataSource.getConnection();
 5    // ... 业务逻辑，如果这里抛出异常 ...
 6    conn.close(); // 这行代码将不会被执行
 7} catch (Exception e) {
 8    // ...
 9}
10
11// 正确示例
12Connection conn = null;
13try {
14    conn = dataSource.getConnection();
15    // ... 业务逻辑 ...
16} catch (Exception e) {
17    // ...
18} finally {
19    if (conn != null) {
20        try {
21            conn.close(); // 确保连接被归还到池中
22        } catch (SQLException e) {
23            // log error
24        }
25    }
26}
```
- 应用日志分析：检查应用日志中是否有数据库连接相关的错误，如“获取连接超时”等。

第三阶段：长期优化与监控

建立监控告警：使用 Prometheus + Grafana 等工具，对 MySQL 的 Threads_connected（当前连接数）、Threads_running（活跃线程数）、Max_used_connections（历史峰值）等关键指标进行监控。设置告警阈值，例如当 Threads_connected / max_connections > 80% 时触发告警。
引入数据库中间件：对于大规模应用集群，可以考虑使用数据库代理/中间件（如 ProxySQL, ShardingSphere-Proxy）。它们可以实现连接复用、读写分离、SQL防火墙等功能，有效管理和优化应用到数据库的连接。
定期审查：将数据库连接池配置和慢查询治理纳入常规技术评审。

常见追问与延伸题目

追问：你说要适当调低 wait_timeout，那调到多低合适？有什么风险？
- 回答要点：wait_timeout 的值需要权衡。理想情况下，它应该略大于应用中最长的 SQL 执行时间。如果设置得太短（比如30秒），而应用中有一个需要执行60秒的正常业务（如数据报表），那么这个连接可能在查询完成前就被服务器端断开，导致应用报错 "The last packet successfully received from the server was ... milliseconds ago"。因此，最佳实践是：首先，优化掉长查询；其次，让 wait_timeout 的值大于业务可接受的最长查询时间，同时小于连接池的 idleTimeout 或 maxLifetime，以确保连接的生命周期由应用侧的连接池主导管理。将它作为清理异常泄露连接的最后一道防线，而不是常规管理手段。
追问：如果应用和数据库之间有 ProxySQL 这样的中间件，排查思路有什么不同？
- 回答要点：排查链路变长了，需要分段排查。连接数打满可能发生在两个地方：
  1. 应用 -> ProxySQL：应用实例请求 ProxySQL 的连接数超过了 ProxySQL 的前端连接上限（mysql-max_connections）。
  2. ProxySQL -> MySQL：ProxySQL 作为一个客户端，其到后端 MySQL 的连接数超过了 MySQL 的 max_connections。
- 排查步骤：首先登录 ProxySQL 的管理端口（SHOW STATS），检查 mysql_connection_pool 表，看后端连接池的使用情况，确认是哪个主机组的连接池被打满。再结合 SHOW PROCESSLIST 在后端 MySQL 上的观察，判断是 ProxySQL 无法建立新连接，还是 ProxySQL 建立的连接在 MySQL 端被卡住。ProxySQL 的连接复用（Multiplexing）机制也可能导致问题，比如一个长事务会独占一个后端连接，使其无法被复用，从而消耗连接池资源。
追问：除了连接数，还有哪些原因会导致应用报“无法连接数据库”？
- 回答要点：这是一个开放性问题，考察知识广度。
  1. 网络问题：应用服务器与数据库服务器之间的网络不通、防火墙策略、DNS 解析失败。可以通过在应用服务器上 ping 或 telnet <db_host> <db_port> 来快速检测。
  2. 数据库认证问题：用户名或密码错误、授权的 IP 限制（'user'@'host'）。检查数据库的 mysql.user 表。
  3. 数据库自身负载极高：CPU 100%、磁盘 I/O 饱和或磁盘空间满，导致数据库无法响应新的连接请求。需要登录服务器用 top, iostat, df 等命令检查系统资源。
  4. 半开连接（Half-Open Connections）：由于网络设备（如防火墙、NAT）的会话超时，导致 TCP 连接在应用和数据库不知情的情况下被中断。应用再次使用该连接时会失败。这通常通过调整 TCP keepalive 参数来解决。