性能瓶颈报告的核心结构
写性能瓶颈报告不是堆数据，而是讲清楚“哪里卡了、为什么卡、怎么解决”。比如你公司系统一到下午三点就卡顿，用户投诉不断，这时候一份清晰的报告能快速推动问题解决。开头直接说明测试背景：哪个系统、什么时间、在什么负载下出现了性能问题。
如何定位瓶颈点
先看监控数据。CPU 使用率持续 90% 以上？内存频繁触发 Swap？还是数据库查询响应超过 5 秒？把这些异常指标列出来。可以用图表辅助，但报告里只放关键图。比如某接口平均响应时间从 200ms 涨到 2s，这种突变点必须标出。
常见瓶颈类型举例
如果是 Web 应用，常见问题是线程阻塞或数据库慢查询。比如发现 MySQL 的 SHOW PROCESSLIST 里一堆 Locked 状态，基本可以断定是锁竞争导致。又或者 Java 应用 Full GC 频繁，堆内存一直降不下来，可能是内存泄漏。
分析过程要具体
不要只说“数据库拖慢了系统”，要说“订单查询接口因未走索引，单次执行耗时 1.8 秒，QPS 超过 50 后响应时间急剧上升”。附上 SQL 语句和执行计划：
<pre>
EXPLAIN SELECT * FROM orders WHERE user_id = 12345;
+----+-------------+--------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+--------+------+---------------+------+---------+------+------+-------------+
| 1 | SIMPLE | orders | ALL | NULL | NULL | NULL | NULL | 100K | Using where |
+----+-------------+--------+------+---------------+------+---------+------+------+-------------+
</pre>给出可落地的建议
发现问题后，建议要具体。比如“为 orders 表的 user_id 字段添加索引”比“优化数据库”有用得多。如果是代码层面的问题，指出具体文件和方法。例如“UserService.java 第 87 行循环中重复创建数据库连接，建议改为连接池复用”。
附录放原始数据
主报告保持简洁，把压测日志、完整监控截图、堆栈跟踪这些放在附录。别人想深挖时有据可查。比如 JMeter 的聚合报告导出 CSV，或者 top -H 抓到的高 CPU 线程 ID，都可以作为附件引用。