先定位，再优化：一次接口变慢的排查笔记

一个接口平时只要两百毫秒，某天突然变成三秒，第一反应往往是加缓存、升配置。可是如果慢的原因不在数据量，而在一次重复查询或者一个没有走索引的条件，扩容只是把问题藏得更深。这篇笔记记录一套更省事的顺序：先复现，再分层定位，最后才谈优化。

一、先把慢说清楚

慢是一个结果，不是原因。动手之前先固定三个信息：哪个接口、哪类请求、在什么条件下变慢。把请求参数、数据规模和时间点记下来，同一条请求多测几次，看耗时是稳定地慢，还是偶尔抖动。稳定地慢多半有确定的瓶颈；偶尔抖动则要先看并发、定时任务和外部依赖。没有这一步，后面的每一次改动都很难验证。

同时区分前端体感和后端耗时。浏览器网络面板里的时间包含排队、传输和渲染，后端日志里的时间才是服务本身的耗时。如果两者差距很大，问题可能在网络、网关或者返回体过大，而不是业务逻辑。

二、按链路分层，而不是凭感觉猜

一次请求通常经过网关、业务服务、缓存、数据库和第三方接口。定位时从外向内切分：先看总耗时，再看各段耗时占比。占比最大的那一段，就是下一步的重点。

如果数据库耗时占比最高，再看是查询本身慢，还是连接等待久。查询慢要看执行计划、返回行数和排序方式；连接等待久则要看连接池大小、慢事务是否长期占用连接。很多看似数据库慢的问题，其实是事务没有及时提交，或者一次请求里发了几十条重复查询。

如果第三方接口耗时最高，先确认超时时间、重试次数和并发上限。一次失败重试三次，耗时就可能翻几倍。重试不是免费的，它会把上游的压力也放大。

三、常见的四种误判

第一，把平均值当成全部。平均耗时正常，不代表长尾正常。百分之九十五分位和最大值更能暴露偶发问题。

第二，把本地快当成线上快。本地数据量小、缓存是热的、网络几乎没有延迟，结论不能直接搬到线上。

第三，把新功能当成唯一嫌疑。慢可能来自数据增长，而不是最近一次上线。按时间对照数据量变化，往往比对照发布记录更有效。

第四，一次改多个地方。改缓存、改索引、改超时一起上，效果好了也不知道是哪一项起作用，效果差了更难回退。一次只改一个变量，改完立刻复测。

四、优化之前先做减法

在加缓存之前，先问三个问题：这条查询能不能少查？返回字段能不能少给？这段逻辑能不能不放在请求里？

能分页的不要一次全量返回，能按需加载的不要提前加载全部关联数据，能异步做的不要阻塞主流程。例如导出、统计和通知，常常可以先返回结果，再由后台任务慢慢完成。把主流程变瘦，本身就是最有效的优化。

缓存适合读多写少、结果相对稳定的数据，不适合频繁变化又要求强一致的数据。加缓存之前要说清楚失效策略和兜底方案，否则缓存过期、穿透和脏数据会带来新的故障。

五、用回归验证收尾

优化完成后，至少做三件事。第一，用同一组参数复测，记录优化前后的耗时对比。第二，跑一遍正常流程和边界流程，确认没有把正确性换成速度。第三，观察一段时间，看长尾耗时是否真的下降，而不是某一次测试刚好变快。

最后留一张排查清单：接口和参数是什么，慢是稳定还是抖动，各段耗时占比是多少，瓶颈在数据库、第三方还是自身逻辑，只改了一个变量吗，回归结果如何。把这张清单贴在团队文档里，下一次接口变慢，就不用从零开始猜了。慢并不可怕，可怕的是没有证据的优化。先定位，再优化，速度自然会回来。