性能案例模板
要点
- 性能案例记录瓶颈定位、优化手段、指标对比
- 重点是定位过程——怎么找到瓶颈的，而不是直接给优化方案
- 用数据说话——优化前后的指标对比，P50/P95/P99
- 性能优化通常有取舍——写清楚代价（复杂度、内存、开发成本）
1. 适用场景
性能案例用于记录系统性能问题的定位和优化过程。
典型场景：
- 接口响应时间过长
- 系统吞吐量不足
- 内存占用过高
- CPU 使用率异常
- 数据库查询慢
2. 模板结构
# [性能问题标题]
## 背景
什么系统、什么接口、什么性能指标、目标是多少。
## 问题描述
- 现象：P99 延迟 2 秒，目标 200ms
- 影响：用户体验差，转化率下降 10%
- 触发条件：订单量 > 10 万/天时出现
## 瓶颈定位
### 第一步：监控数据
- P50: 50ms, P95: 200ms, P99: 2000ms
- CPU: 30%, 内存: 40%, 数据库连接: 80%
- 结论：CPU 和内存正常，数据库连接可能是瓶颈
### 第二步：链路追踪
- 订单 API → 用户服务（20ms）→ 商品服务（30ms）→ 订单数据库（1800ms）
- 结论：瓶颈在订单数据库
### 第三步：慢查询分析
- 开启慢查询日志，发现 3 条慢查询
- 最慢的查询：查询订单列表，平均耗时 1.5 秒
- 原因：缺少索引，全表扫描
## 优化方案
### 方案 1：添加索引
在 `orders` 表的 `user_id` 和 `created_at` 字段添加复合索引。
效果：
- 查询时间从 1.5s 降到 50ms
- P99 延迟从 2s 降到 150ms
代价：
- 写入性能下降 10%（索引维护开销）
- 磁盘空间增加 2GB
### 方案 2：查询优化（备选）
把关联查询拆成两次查询，减少 JOIN 开销。
效果：
- 查询时间从 1.5s 降到 200ms
- 但需要改代码，影响范围大
## 结果
采用方案 1（添加索引）：
| 指标 | 优化前 | 优化后 | 改善 |
|------|--------|--------|------|
| P50 | 50ms | 30ms | 40% |
| P95 | 200ms | 80ms | 60% |
| P99 | 2000ms | 150ms | 92% |
| QPS | 500 | 800 | 60% |
## 复盘
- 瓶颈定位的关键是链路追踪，快速定位到数据库
- 慢查询监控要提前建设，不要等出问题再开
- 索引不是万能的，写入密集的场景要权衡
- 后续行动：添加慢查询实时监控告警3. 写作要点
定位过程比方案更重要
不要直接写「添加索引解决了问题」。要写：
- 怎么发现性能问题（监控、用户反馈）
- 怎么定位瓶颈（链路追踪、慢查询日志、火焰图）
- 为什么是这个瓶颈（证据）
用数据说话
性能案例必须有数据：
- 优化前后的指标对比（P50/P95/P99、QPS、吞吐量）
- 资源使用率（CPU、内存、磁盘、网络）
- 具体的改善百分比
写清楚取舍
性能优化通常有代价：
- 添加索引 → 写入性能下降
- 增加缓存 → 数据一致性复杂度
- 异步处理 → 最终一致性
写清楚代价，读者才能判断是否值得。
定位方法论
常用的性能定位方法：
- 监控指标：P50/P95/P99、QPS、资源使用率
- 链路追踪：分布式系统的调用链路，找到最慢的环节
- 慢查询日志：数据库的慢查询，分析索引和查询计划
- 火焰图：CPU 热点分析，找到耗时的函数
- 内存分析：内存泄漏、GC 频率
4. 常见误区
只写方案，不写定位过程
「添加索引解决了问题」不是案例，是操作手册。要写：怎么发现慢、怎么定位到数据库、怎么确认是索引问题。
没有数据对比
「性能提升了」不是结论。要写：P99 从 2s 降到 150ms，提升 92%。
忽略取舍
「添加索引是最佳方案」太绝对。要写：添加索引提升了查询性能，但写入性能下降 10%，在可接受范围内。
总结
性能案例的核心是瓶颈定位过程。用数据说话（优化前后对比），写清楚定位方法（链路追踪、慢查询日志），承认取舍（索引影响写入性能）。