日志里藏着的慢查询：一次接口变慢排查的三点实用经验

上周，我们一个订单查询接口的 P99 延迟突然从 80 毫秒涨到 2.3 秒，报错率却没有明显上升。告警只说接口变慢，没有告诉我们慢在哪里。这次排查只用了不到两小时，靠的不是高深工具，而是三条很朴素的经验，分享出来供遇到同类问题的开发者参考。

一、先对齐时间，再看日志

接口变慢的第一反应往往是翻日志，但如果各服务时间没有对齐，日志顺序本身就会误导人。我们先确认了所有节点的时钟偏差在毫秒级，然后按请求 ID 把网关、业务服务和数据库的日志串起来。结果发现：业务服务收到请求后 1.8 秒才发出第一条 SQL，问题不在数据库，而在服务内部。这一步省掉了大量无用功——如果直接盯着慢 SQL，很可能在错误的方向上越走越远。

二、把“慢”拆成三段再定位

我们把一次请求拆成三段分别计时：网络与网关耗时、业务处理耗时、数据库耗时。监控显示网关耗时正常，数据库平均耗时只有 40 毫秒，业务处理耗时却占了九成以上。顺着这条线索继续下钻，发现一个缓存键的生成逻辑在数据量变大后退化成了全量扫描：每次请求都要遍历一份不断增长的配置列表。根因不是数据库慢，也不是网络抖动，而是一段平时不起眼的内存计算。

三、修完要留证据，不要只凭感觉

定位根因后，我们把配置列表改成按需加载加本地缓存，并给关键步骤加上分段耗时日志。修复上线后，P99 回到 90 毫秒左右，连续观察两天没有反弹。更重要的是，我们把排查过程写进了团队的故障记录：现象、时间线、证据链、根因和验证结果。这样下次再遇到类似告警，任何人都能按图索骥，而不是从头摸索。

小结：给排查留一张清单

接口变慢时，可以按这个顺序走：第一，对齐时间，用请求 ID 串联各环节日志；第二，分段计时，先确定慢在哪一段，再在段内下钻；第三，修复后保留可复核的证据和记录。慢查询很少是单一原因造成的，但排查方法可以是确定的。把每一次排查都沉淀下来，系统和团队都会越来越稳。