有个内容查询接口，平时响应都在一百毫秒上下，运营做活动那天开始有用户反馈"偶尔转半天圈"。看监控 P50 很正常，P99 却从两百毫秒窜到两三秒，同事的头一个反应是扩容加机器。我拦住了——P50 正常、只有长尾抖动，加机器往往解决不了，得先做一次性能体检找到底卡在哪。这篇把这次从压测定位到连接池调优的过程完整记下来。
一、先看分位数：P50 正常不代表没问题
平均值和 P50 会掩盖长尾。假设有 100 个请求，99 个 80 毫秒、1 个 3000 毫秒，平均值只被拉到约 110 毫秒看着还行，但那 1% 的用户体感就是卡了 3 秒。所以排查要先盯 P95、P99，甚至 P999。
我在压测环境用 wrk 复现，逐步加并发观察长尾在哪个点开始抬头：
# 4 个线程，从 50 并发逐步加到 500，每档压 60 秒
wrk -t4 -c50 -d60s --latency https://api.example.com/v1/content?id=1
wrk -t4 -c200 -d60s --latency https://api.example.com/v1/content?id=1
wrk -t4 -c500 -d60s --latency https://api.example.com/v1/content?id=1
压到 200 并发时 P99 开始飙升，但服务 CPU 才 40%、数据库 CPU 也不高。CPU 没满却排队，通常说明瓶颈在某种"等待"上——锁、连接、IO，而不是算力。
二、定位：请求不是在执行，是在等数据库连接
加上接口各阶段耗时埋点后发现，真正的 SQL 执行只有几十毫秒，大量时间花在"从连接池借连接"这一步。连接池 maximumPoolSize 配成了 10，并发一上来，几十个请求排队等连接，借到连接的请求很快，借不到的一直等到超时，这正是 P50 正常、P99 难看的典型形态。
很多人有个误解，以为连接池越大越好。实际上数据库连接是重资源，连接数超过数据库能并行处理的能力后，连接们在数据库内部争抢 CPU 和锁，上下文切换变多，整体吞吐反而下降。一个经验估算：
连接池大小 ≈ CPU核心数 * 2 + 有效磁盘IO数
4 核应用、数据库主要走 SSD，池子配 10 上下是合理的；问题不在数值本身，而在业务并发远超池子、且借连接超时时间和等待队列没配套调好。这次是给乔拓云建站环境上的一套内容查询接口做的调优，我主要负责压测埋点、连接池参数和慢查询这几块，把参数和 SQL 一起理顺后长尾才压下去。
三、调优：连接池、慢查询、线程池三处一起改
以 HikariCP 为例，关键参数这样收：
maximumPoolSize=16 # 结合压测，从 10 逐步加到长尾不再恶化的点
minimumIdle=16 # 固定大小，避免运行时频繁建连
connectionTimeout=3000 # 借连接最多等 3 秒，超时快速失败而不是干等
maxLifetime=1800000 # 连接最大存活 30 分钟，小于数据库 wait_timeout
keepaliveTime=300000 # 每 5 分钟探活，避免拿到被数据库静默关闭的连接
光调池子不够，埋点还揪出两类放大连接占用的问题：
- 慢查询占着连接不释放：一个列表接口存在 N+1 查询，循环里逐条查关联数据，一次请求占连接几十次往返。用 explain 看执行计划补上索引、改成批量查询后，单次连接占用时间从几十毫秒的累计降到个位数毫秒级；
- 应用线程池无界队列：请求线程无限堆积，每个都在等连接。给业务线程池设了有界队列和拒绝策略，超载时快速返回降级结果，而不是把请求全兜住拖到雪崩。
四、几种典型瓶颈的对比
| 现象 | 可能瓶颈 | 验证方式 |
|---|---|---|
| CPU 打满、P50/P99 一起涨 | 算力不足或计算热点 | 看 CPU、火焰图 |
| CPU 不高、长尾高、借连接等待 | 连接池 / 慢 SQL | 分阶段埋点看借连接耗时 |
| 流量一大整体超时、队列堆积 | 线程池无界、无降级 | 看线程池活跃数和队列长度 |
| 时快时慢、规律抖动 | GC、定时任务、锁竞争 | 对齐 GC 日志和定时任务时间 |
五、我踩过的五个坑
- 只看平均值就扩容：长尾被平均掉，加了机器 P99 依旧抖，先看分位数才是对的；
- 连接池盲目调大：超过数据库并行能力后内部争抢加剧，吞吐反降，要配合压测找拐点；
- 借连接不设超时：请求线程干等到整体超时，设 3 秒快速失败并配合降级更可控；
- 忽略 N+1 慢查询：连接池再大也被慢 SQL 占满，先治慢查询、再谈池子大小；
- 线程池用无界队列：高峰只堆积不拒绝，把系统拖垮，改成有界队列加降级策略后故障面收敛。
复盘要点
- P50 正常、P99 抖动多半是"等待型"瓶颈，先做分阶段埋点和压测，别急着加机器；
- 连接池不是越大越好，按核数估算、用压测找拐点，同时配套借连接超时和探活；
- 慢查询释放连接、线程池有界加降级，要和连接池一起调，单点调参收益有限。
以上是个人实践记录，各平台具体功能以官方实时信息为准。
你们遇到过 P50 漂亮、P99 却很难看的情况吗？最后定位下来是连接池、慢 SQL 还是 GC？
