案例复盘：一次接口变慢的排查全过程

把一次典型的接口变慢排查按时间线摆出来，比罗列十条抽象经验更有用。以下场景在业务系统里反复出现，处理思路可以照搬。排查顺序从便宜到昂贵：先看监控，再上机，最后动数据库。 背景：某业务反馈下单接口时快时慢，下午高峰尤其明显，应用日志里没有报错。 一、先看监控定方向 接口平均响应从 100 毫秒爬到 1.5 秒；同机 CPU、内存、网卡流量都平稳；磁盘 util 曲线间歇冲到 95% 以上。对比要找参照物：和上周同期比、和低峰比，别只盯绝对值；平均值与分位数一起看，只有部分请求变慢时均值会撒谎。四个方向里，应用不忙而磁盘很忙，第一嫌疑人转向存储。 二、上机确认瓶颈 iostat -x 1 显示数据盘 %util 长期高位，await 从平时的 5 毫秒涨到 200 毫秒；iotop 观察到大量 IO 读写来自数据库进程；CPU 的 wa 列与 util 曲线互相印证。这一步五分钟够用，工具都是现成的，关键是知道先看哪块。链路收敛为：磁盘忙，数据库慢，接口跟着慢。 三、数据库侧找元凶 慢查询日志（slow_query_log 已开，long_query_time=1）里抓到一条统计 SQL，全表扫描百万行；EXPLAIN 显示没有可用索引，type 为 ALL。对照上线记录，运营后台新加的报表任务每小时整点跑一次，正好压在业务高峰上，大查询吃满磁盘 IO，拖慢同盘上的所有查询。报表、统计、清理任务是这类问题的高发形态，上线记录是最好的线索库。 四、改进落点 给统计 SQL 补上联合索引，扫描行数降到千级；报表任务挪到凌晨并限制并发；接口层补超时与降级；监控增加磁盘 util 与慢查询数量两条告警，同类问题下次直接报警。改进后压一轮高峰，接口响应回到基线才算收尾。 复盘的价值不在这一次，而在逐层定位的顺序：网关、应用、存储、依赖。监控数据齐全的话，锁定方向通常不超过十分钟。