性能问题不是玄学，是有迹可循的过程
你有没有遇到过这样的情况？系统早上还好好的，下午突然变慢，接口响应从200毫秒飙到3秒，用户开始抱怨，领导急着要答案。这时候别慌，性能分析流程就是帮你从混乱中理出头绪的工具。
它不是靠猜，也不是靠重启大法，而是一套有逻辑、可复现的排查路径。很多人一上来就看CPU、内存，结果绕了一圈发现是数据库索引丢了。
第一步：明确现象，别被表象带偏
先搞清楚到底哪里慢。是整个系统卡？还是某个功能点？比如后台导出报表特别慢，但其他页面正常。这时候就要记录具体时间、操作路径、用户角色，甚至网络环境。有时候问题只出现在特定浏览器或内网环境下。
可以用最原始的办法——记日志。用户点击“导出”按钮，几时几分几秒，系统返回耗时多久，中间有没有报错。把这些信息收集起来，比听用户说“就是慢”有用得多。
第二步：分层排查，像剥洋葱一样
系统一般分几层：前端、网关、应用服务、数据库、存储。一层层往下查，别跳。
前端看加载时间，F12打开Network选项卡，看是静态资源卡，还是API请求拖后腿。如果是API慢，接着看网关有没有限流或转发延迟。再到应用服务，查JVM状态、线程堆积情况。最后到数据库，看慢查询日志。
举个例子，有次线上订单创建变慢，查到最后发现是Redis连接池被打满，根源却是上游一个定时任务频繁刷缓存，没加开关控制频率。
第三步：抓关键指标，别被数据淹没
监控图表一堆线，别光盯着CPU 80%吓自己。关键看几个核心指标：响应时间、吞吐量、错误率、GC频率、数据库查询耗时。
比如Java服务，用jstat看GC情况，如果Young GC频繁，可能对象创建太多；Full GC间隔短，可能是内存泄漏。用jstack抓线程栈，看有没有大量线程卡在同一个方法上。
数据库方面，MySQL开慢查询日志，设置阈值1秒，跑一段时间看哪些SQL上榜最多。有时候一个没走索引的查询，就能拖垮整个服务。
SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 1;
SET GLOBAL log_output = 'TABLE';第四步：复现与验证，别急着下结论
找到疑似问题后，别马上改生产。先在测试环境复现。用压测工具模拟用户行为，比如用JMeter跑登录+下单流程，对比优化前后的TPS变化。
有一次发现接口慢，怀疑是序列化问题，换成Protobuf后本地快了，但线上提升不明显。后来才发现瓶颈在网络传输，对方服务响应本身就慢，自己这边再怎么优化也白搭。
所以验证要全面，不能只看单一指标。改完之后观察至少一个完整业务周期，确认问题真解决了，而不是转移了。
第五步：沉淀记录，下次不用从头来
每次性能问题解决后，把排查过程记下来：什么现象、怎么定位、改了什么、效果如何。团队共享，变成知识库的一部分。
下次类似问题出现，直接翻记录，省下大量时间。甚至可以做成检查清单，比如“接口变慢 checklist”，新同事也能快速上手。
性能分析流程不是一次性的救火行动，而是持续改进的习惯。系统会越来越复杂，但只要流程在，就不怕问题多。