性能优化案例表达#

模板： “在[场景]下，通过[监控]发现[异常]，使用[工具]定位到[根因]，通过[方案]解决，[量化提升]“

性能优化案例的表达一定要有完整的链路，我总结为”发现-定位-方案-效果”四步法。首先是怎么发现问题的，比如通过监控告警发现某接口P99延迟从200ms飙到了2s，或者压测时发现吞吐量上不去；然后是定位过程，用了什么工具，比如用explain分析SQL发现全表扫描，用Arthas的trace命令定位到哪个方法耗时最长，用GC日志发现Full GC频繁；接着是优化方案，比如给慢SQL加了组合索引、把同步调用改成异步、调整了JVM堆内存参数；最后一定要有量化效果，RT从2s降到了200ms，GC频率从每分钟一次降到每小时一次。面试官重点关注的是你的排查思路和工具使用能力，而不是结果本身。有两个常见错误要避免：一是效果数据不切实际，比如说RT从1秒优化到1毫秒，这会被直接质疑；二是只说结果不说过程，让人觉得你只是执行了别人的方案。如果某次优化上线后指标反而变差、回滚后查清了原因（比如加缓存后热点 key 失效引发击穿），把这段完整讲出来也是好素材，说明你有真实的线上经验。

追问方向：

• “怎么证明优化效果？”→ 用监控数据做优化前后对比：同一接口、流量相近的时段（避开大促等干扰），看 P99/P999 RT、QPS、错误率的变化趋势；压测用同一脚本、同一环境对比吞吐量；给出具体数字，比如”P99 从 2s 降到 200ms，降了 90%”
• “优化过程踩了什么坑？”→ 准备一个真实的踩坑案例，比如”给区分度很低的字段加了索引，强制走索引后大量回表，比全表扫描还慢""缓存加了但没考虑一致性导致数据错乱”，展示你在实践中的学习过程
• “优化后反而下降了怎么办？”→ 先回滚到优化前版本止损，再分析原因（可能是缓存穿透、锁竞争加剧、GC 参数不当等）；这类经历反而是好素材，说明你有复杂场景下的真实实战经验

易错点：

• ❌ 只报平均 RT——平均值会掩盖长尾，接口优化要报 P99/P999，否则面试官会追问”慢请求有没有改善”
• ❌ “Full GC 频繁就把堆调大”——先用 GC 日志 + 堆 dump（MAT 看 Dominator Tree）判断是不是内存泄漏；泄漏时调大堆只是推迟 OOM，而且堆越大单次 Full GC 停顿越长
• ❌ “加了索引就变快了”——要用 explain 核对 type/key/rows/Extra，确认没有因为对索引列用函数、隐式类型转换、不满足最左前缀而失效