日志先行：一次接口变慢的排查笔记

上周，一个平时两百毫秒左右的查询接口突然涨到三四秒，偶尔还会超时。先加机器、加缓存未必有用，更稳妥的顺序是：先画时间线，再分层定位，最后才改代码或配置。

一、先画时间线

先确认变慢从何时开始，是全量变慢还是个别用户变慢，是否刚好赶上发布、配置变更、数据导入或流量高峰。再把日志里的请求标识和耗时分段放在一起，很多问题立刻就有了边界。个别用户慢，要看这批用户的共同点；全量变慢，要先查数据库、缓存和外部依赖等公共链路。

二、看分布，不只看平均值

平均耗时很容易骗人：九个一百毫秒、一个十秒的请求，平均值超过一秒，但大多数人其实并不慢。所以要看 P95、P99、最大耗时和慢请求占比，再把一次请求拆成网关、应用、数据库、外部调用四段，哪一段变大就先查哪一段。

三、数据库是最常见的慢点

常见形态有四种：缺少索引导致全表扫描；返回字段或数据量过大；循环里逐条查库的 N+1 问题；页码越深扫描越多的深分页。先看慢查询记录和执行计划，确认扫描行数与是否走索引，能用批量查询、限制字段、游标分页解决的，就不要先上重办法。写事务太长、批量更新不分批，也会让读请求排队等待锁。

四、缓存失效要分清三种样子

穿透是数据根本不存在，每次都打到数据库；击穿是热点键刚好过期，大量请求同时回源；雪崩是一批键集中过期，数据库瞬间被压垮。对不存在的数据做短期空值缓存，对热点键用逻辑过期加后台刷新，对大批量过期把时间打散。缓存只是加速手段，不能代替对查询本身的优化。

五、外部依赖和重试会放大故障

调用外部服务要设合理超时，区分可重试与不可重试错误。没有超时控制，下游一慢，上游线程池就会被占满；没有上限和退避的重试，则会把一次故障变成多次冲击。统计外部调用的成功率、超时率和重试次数，就能判断是下游真的慢，还是重试放大了流量。

六、修好之后要能证明

小范围验证同一批慢请求是否恢复、P99 是否回落、慢查询是否减少、缓存命中率是否正常，不要只看本地打开快了。最后留一份简短复盘：现象、时间线、根因、改动、验证指标和后续监控。接口变慢通常是数据量、调用量和小变更叠加的结果，日志先行、分层定位、验证闭环，就是最便宜的排查路线。