MySQL 连接池打满不是 max_connections 的锅：一次 P99 从 80ms 飙到 12s 的复盘

一、现象与背景

2024 年 3 月，某中型电商订单服务在内部压测中出现了严重的性能退化：

数据库：MySQL 8.0.35，max_connections = 1000，innodb_buffer_pool_size = 8G
应用侧：Java 17 + HikariCP 5.1.0，maximumPoolSize = 50，connectionTimeout = 30000（30s）
业务线程池：Tomcat maxThreads = 200
压测场景：模拟 500 并发下单，其中混入 5% 的"历史订单查询"接口

压测跑了 3 分钟，监控面板上出现了让人困惑的画面：

| 指标 | 数值 | |---|---| | MySQL Threads_connected | 127 / 1000（才用了 12.7%） | | HikariCP active | 50 / 50（池子满了） | | HikariCP pending | 83（83 个线程在排队等连接） | | 接口 P99 | 12,430 ms（正常 80 ms，涨了 155 倍） | | 上游 Nginx 502 | 2,147 次 |

最反直觉的一点：数据库连接数才 127，离上限 1000 远得很，但应用侧已经全面雪崩了。 很多人第一反应是"把 max_connections 调到 5000 就好了"——这是错的，下面解释为什么。

二、原理与根因分析

2.1 连接池 ≠ 数据库连接数

max_connections 是 MySQL 服务端能同时接受的最大 TCP 连接数，它是一个全局上限。而 HikariCP 的 maximumPoolSize = 50 是本应用实例能持有的最大连接数。两者不在同一个维度上。

真正的瓶颈链路是：

200 个 Tomcat 线程
  → 竞争 50 个 HikariCP 连接
    → 每条连接上执行 SQL
      → 如果某条 SQL 耗时 2.3s，这条连接就被"占住" 2.3s

2.2 慢 SQL 的"占坑"效应

排查发现，5% 的"历史订单查询"接口里有一条 SQL 没走索引：

SELECT * FROM order_detail
WHERE order_id IN (SELECT id FROM orders WHERE user_id = ?)
  AND created_at < '2020-01-01'
ORDER BY created_at DESC
LIMIT 50;

在 order_detail 表 4,200 万行的数据量下，这条 SQL 在 5% 并发命中时，单次执行耗时从正常的 12ms 退化到 2,340ms（全表扫描 + 排序 + 临时表）。

关键计算：

500 并发 × 5% = 25 个慢请求
每个慢请求占住一条连接 2.3s
50 个连接在 2.3s 内全部被慢请求"锁死"
剩余 475 个正常请求全部进入 pending 队列
每个等待线程最多等 30s（connectionTimeout），30s 后抛 SQLTransientConnectionException: Connection is not available, request timed out after 30003ms

结论：不是 MySQL 连不上了，而是 50 个连接全部被慢 SQL 占着不还。 max_connections 调再大也救不了，因为瓶颈在应用侧的连接池容量。

2.3 为什么"偶尔慢"在并发下变成"全线慢"

单条 SQL 慢 2s，如果只有 1 个请求，用户觉得"慢了点"。但当 25 个慢请求同时到来，它们同时占住 25 条连接，剩下的 25 条连接在 2.3s 内被正常请求消耗完，之后所有新请求只能排队。这是一个正反馈的雪崩：排队 → 等待 → 更多线程被阻塞 → 上游超时重试 → 并发更高 → 更多排队。

三、具体做法（可复现）

3.1 给 SQL 加"熔断器"——max_execution_time

MySQL 8.0.22+ 支持 max_execution_time（单位 ms），在会话级别限制单条 SQL 最长执行时间：

-- 在 HikariCP 的 connectionInitSql 里加
SET SESSION max_execution_time = 3000; -- 3 秒，超过直接 KILL

HikariCP 配置：

spring:
  datasource:
    hikari:
      maximum-pool-size: 50
      minimum-idle: 10
      connection-timeout: 5000      # 从 30s 降到 5s，快速失败
      idle-timeout: 600000
      max-lifetime: 1800000
      connection-init-sql: "SET SESSION max_execution_time = 3000"

⚠️ max_execution_time 只对 DML（SELECT/INSERT/UPDATE/DELETE）生效，DDL 不受限。

3.2 修掉那条慢 SQL

-- 加复合索引
ALTER TABLE order_detail
  ADD INDEX idx_user_created (user_id, created_at DESC);

-- 改写 SQL，避免子查询
SELECT od.*
FROM order_detail od
JOIN orders o ON od.order_id = o.id
WHERE o.user_id = ?
  AND od.created_at < '2020-01-01'
ORDER BY od.created_at DESC
LIMIT 50;

加索引后 EXPLAIN 显示 type: ref，执行时间从 2,340ms 降到 8ms。

3.3 应用侧加超时保护（双保险）

// 用 CompletableFuture 给数据库操作加硬超时
Future<PageResult<Order>> future = executor.submit(() ->
    orderMapper.queryHistory(userId, cutoff)
);
try {
    return future.get(2, TimeUnit.SECONDS);  // 2s 硬超时
} catch (TimeoutException e) {
    future.cancel(true);
    throw new BizException("查询超时，请稍后重试");
}

3.4 监控告警

在 Grafana 面板加两条告警：

# HikariCP 活跃连接占比 > 80% 持续 30s
hikaricp_connections_active / hikaricp_connections_max > 0.8

# 慢查询（> 1s）QPS
rate(mysql_global_status_slow_queries[1m]) > 0.5

四、踩过的坑与反直觉之处

"max_connections 很大就安全了"是错觉。 1000 个连接是 MySQL 服务端的能力，但你的应用只有 50 个连接池。瓶颈永远在最小环节，调大最大环节没有意义。
慢 SQL 不是"偶尔慢"，是"并发下必慢"。 单条 2s 的 SQL 在 1 个并发时只是"慢"，在 25 个并发时是"雪崩"。压测时不加 5% 的慢查询比例，你永远发现不了这个坑。
connectionTimeout = 30s 太长了。 30s 意味着一个用户请求要等 30s 才报错，上游 Nginx 的 proxy_read_timeout 通常只有 60s，两个超时叠加，用户看到的是"页面卡了 30 多秒才出 502"。降到 5s，用户 5s 内就能收到错误并重试。
HikariCP 的 maximumPoolSize 不是越大越好。 调到 200 看似"够用"，但 200 个连接同时打到 MySQL，innodb_buffer_pool 的命中率从 99.2% 掉到 71%，磁盘 IO 飙升，整体更慢。经验值：池子大小 ≈ CPU 核数 × 2 + 磁盘 spindle 数（HikariCP 官方建议），50 对 8C16G 的实例是合理的。
max_execution_time 不是万能的。 它只 KILL 当前会话的当前查询，如果连接还在事务中（BEGIN 后未 COMMIT），连接不会被释放。所以它必须配合应用侧的事务超时一起用。

五、结论与可复用清单

一句话结论： 连接池打满的根因 90% 的情况不是"连接不够"，而是"连接被慢 SQL 占着不还"。

避坑清单（可直接贴到团队 Wiki）

[ ] 压测必须混入 5% 慢查询流量，只压"快路径"等于没压
[ ] HikariCP connectionTimeout ≤ 5s，快速失败 > 慢慢等
[ ] 所有 SELECT 必须走索引，EXPLAIN 里出现 type: ALL 直接打回
[ ] 加 max_execution_time 会话级熔断（MySQL 8.0.22+），建议 3000ms
[ ] 应用层加 Future.get(timeout) 硬超时，双保险
[ ] 监控 HikariCP active/max 占比，> 80% 告警
[ ] 不要盲目调大 max_connections，先查是谁在占连接
[ ] 事务要短，BEGIN 和 COMMIT 之间不要放 RPC 调用 / 文件 IO
[ ] 慢查询日志要开：slow_query_log = ON，long_query_time = 0.5（0.5s 就开始记）
[ ] 大促前做一次"连接池压力测试"：模拟 50 个连接全部被慢 SQL 占住，观察系统是否优雅降级而非雪崩

本文基于 2024 年 3 月一次真实压测事故复盘，所有参数值、耗时数字均为实际监控截图数据。

赞 0 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。