拓冰网站定制 
下午三点客服群里突然炸了。用户反馈订单详情页转圈圈打不开我扫了一眼监控大屏——/order/detail接口的 P99 延迟从平时的 200ms 飙到了 3.2 秒QPS 没变但错误率开始抬头。杨工是不是数据库挂了 小刘凑过来一脸紧张。别猜。 我拉过一把椅子接口变慢是面试里出镜率最高的场景也是线上最让人头疼的问题。记住排查的核心就一句话自顶向下三步走。先定位慢在哪一跳再分析这一跳为什么慢最后下沉到根因。不按顺序、上来就瞎猜是面试和实战的大忌。第一步链路追踪——锁定慢在哪一跳我先看链路。有 APM 吗小刘有SkyWalking。我点开 SkyWalking 的 Trace 详情页瀑布图一目了然/order/detail 3200ms ├─ OrderService.detail 180ms ├─ UserRPC.getUser 2400ms │ └─ MySQL.select 2350ms ← 慢在这里 └─ Redis.get 12ms我看到了吗OrderService 本身只花了 180msRedis 12ms真正拖后腿的是 UserRPC 调用的那条 SQL占了 2350ms。排查范围从整个系统缩小到这一次 SQL 调用。小刘那要是没有 APM 怎么办我那就自建。网关过滤器生成一个traceId塞进 MDC用 AOP 切面记录每个方法的耗时打日志。排查时grep traceId app.log就能还原一次请求的耗时分布。原理一样——先缩小范围再精准打击。第二步服务层分析——排除三类资源问题小刘那直接去看 SQL我别急。定位到慢的服务后先别急着看 SQL逐一排除三类资源问题。我给他列了一张表排查对象看什么结论线程池active长期等于max队列持续上涨线程池打满——查下游为什么都这么慢而不是只调大线程数数据库连接池Druid 的getWaitThreadCount() 0强信号连接被慢 SQL 占着不还直接进第三步JVMGC 日志 / Arthasdashboard频繁 GC 停顿导致偶发慢转 Full GC 排查流程小刘我看了线程池正常连接池也没堆积GC 也正常。我好排除完毕。那问题就锁定在 SQL 本身了。进入第三步。第三步SQL 执行计划——定位根因我拿到那条慢 SQL先EXPLAIN一下。EXPLAIN SELECT * FROM user_order WHERE DATE(create_time) 2026-07-20 AND user_id 12345;小刘出来了……type ALLkey NULLrows 1200000Extra里还有Using filesort。我全表扫描 120 万行还用了文件排序不慢才怪。你看 WHERE 条件——DATE(create_time) 2026-07-20这就是经典陷阱索引列上套了函数索引直接失效。我把生产环境最常见的索引失效写法清单推给他WHERE DATE(create_time) 2026-07-20 -- 索引列套函数 → 改范围查询 WHERE phone 13800138000 -- varchar 列传数字隐式类型转换 WHERE order_no LIKE %ABC123 -- 前导模糊查询 WHERE b 1 AND c 2 -- 联合索引(a,b,c)不满足最左前缀 WHERE status 1 OR remark urgent -- OR 连接非索引列 → 拆 UNION小刘那怎么改我把函数去掉改成范围查询再补一个索引-- 改前DATE(create_time) 2026-07-20全表扫描 120 万行耗时 2.3 秒 -- 改后 WHERE create_time 2026-07-20 00:00:00 AND create_time 2026-07-21 00:00:00 -- 建索引 idx_ctime(create_time)执行计划变 typerange, rows≈800耗时降到 18ms小刘从 2.3 秒到 18ms……这也太爽了。现场定位神器Arthas我如果想在生产环境实时看方法内部哪一步慢还有一个神器——Arthas。# 追踪方法内部每一步耗时只看超过 1 秒的调用 trace com.example.OrderService detail #cost 1000 # 看方法的入参和返回值 watch com.example.OrderService detail {params, returnObj} -x 2小刘不用改代码、不用重启直接 attach 上去就能看我对。线上排查的终极武器。常见根因优先级小刘杨工如果面试问接口慢怎么排查我按什么顺序说我按命中率排序这样说最稳慢 SQL索引失效 / 数据量增长——超过一半的慢接口都栽在这先EXPLAIN。缓存失效或击穿——请求穿透到 DB查缓存策略和热点 key。下游 RPC 慢——链路追踪看瀑布图。GC 停顿——转 Full GC 排查流程。锁竞争——jstack看线程阻塞。线程池排队——查线程池配置和下游响应时间。记住先说最常见的再展开面试官会觉得你实战经验丰富。常态防御——收尾必说小刘修好了就完了我当然不。收尾一定要说常态防御这是加分项开启慢查询日志SET long_query_time 1;定期用mysqldumpslow -s t -t 10出 TOP 10 慢 SQL主动优化。配合压测和缓存预热防复发。核心接口加监控告警RT 超过阈值自动通知。尾声修复上线后/order/detail接口的 P99 延迟回到了 180ms。小刘杨工今天学到的东西够我吹半年面试了。我记住排查接口慢就像破案链路追踪缩小范围→服务层排除资源问题→SQL 执行计划定位根因。套路熟了线上就不慌了。他点点头补了一句还有以后写 SQL 我一定先EXPLAIN再上线。我笑了这才是今晚最大的收获。c 3秒的订单：一次接口RT飙高的“破案“实录
下午三点客服群里突然炸了。用户反馈订单详情页转圈圈打不开我扫了一眼监控大屏——/order/detail接口的 P99 延迟从平时的 200ms 飙到了 3.2 秒QPS 没变但错误率开始抬头。杨工是不是数据库挂了 小刘凑过来一脸紧张。别猜。 我拉过一把椅子接口变慢是面试里出镜率最高的场景也是线上最让人头疼的问题。记住排查的核心就一句话自顶向下三步走。先定位慢在哪一跳再分析这一跳为什么慢最后下沉到根因。不按顺序、上来就瞎猜是面试和实战的大忌。第一步链路追踪——锁定慢在哪一跳我先看链路。有 APM 吗小刘有SkyWalking。我点开 SkyWalking 的 Trace 详情页瀑布图一目了然/order/detail 3200ms ├─ OrderService.detail 180ms ├─ UserRPC.getUser 2400ms │ └─ MySQL.select 2350ms ← 慢在这里 └─ Redis.get 12ms我看到了吗OrderService 本身只花了 180msRedis 12ms真正拖后腿的是 UserRPC 调用的那条 SQL占了 2350ms。排查范围从整个系统缩小到这一次 SQL 调用。小刘那要是没有 APM 怎么办我那就自建。网关过滤器生成一个traceId塞进 MDC用 AOP 切面记录每个方法的耗时打日志。排查时grep traceId app.log就能还原一次请求的耗时分布。原理一样——先缩小范围再精准打击。第二步服务层分析——排除三类资源问题小刘那直接去看 SQL我别急。定位到慢的服务后先别急着看 SQL逐一排除三类资源问题。我给他列了一张表排查对象看什么结论线程池active长期等于max队列持续上涨线程池打满——查下游为什么都这么慢而不是只调大线程数数据库连接池Druid 的getWaitThreadCount() 0强信号连接被慢 SQL 占着不还直接进第三步JVMGC 日志 / Arthasdashboard频繁 GC 停顿导致偶发慢转 Full GC 排查流程小刘我看了线程池正常连接池也没堆积GC 也正常。我好排除完毕。那问题就锁定在 SQL 本身了。进入第三步。第三步SQL 执行计划——定位根因我拿到那条慢 SQL先EXPLAIN一下。EXPLAIN SELECT * FROM user_order WHERE DATE(create_time) 2026-07-20 AND user_id 12345;小刘出来了……type ALLkey NULLrows 1200000Extra里还有Using filesort。我全表扫描 120 万行还用了文件排序不慢才怪。你看 WHERE 条件——DATE(create_time) 2026-07-20这就是经典陷阱索引列上套了函数索引直接失效。我把生产环境最常见的索引失效写法清单推给他WHERE DATE(create_time) 2026-07-20 -- 索引列套函数 → 改范围查询 WHERE phone 13800138000 -- varchar 列传数字隐式类型转换 WHERE order_no LIKE %ABC123 -- 前导模糊查询 WHERE b 1 AND c 2 -- 联合索引(a,b,c)不满足最左前缀 WHERE status 1 OR remark urgent -- OR 连接非索引列 → 拆 UNION小刘那怎么改我把函数去掉改成范围查询再补一个索引-- 改前DATE(create_time) 2026-07-20全表扫描 120 万行耗时 2.3 秒 -- 改后 WHERE create_time 2026-07-20 00:00:00 AND create_time 2026-07-21 00:00:00 -- 建索引 idx_ctime(create_time)执行计划变 typerange, rows≈800耗时降到 18ms小刘从 2.3 秒到 18ms……这也太爽了。现场定位神器Arthas我如果想在生产环境实时看方法内部哪一步慢还有一个神器——Arthas。# 追踪方法内部每一步耗时只看超过 1 秒的调用 trace com.example.OrderService detail #cost 1000 # 看方法的入参和返回值 watch com.example.OrderService detail {params, returnObj} -x 2小刘不用改代码、不用重启直接 attach 上去就能看我对。线上排查的终极武器。常见根因优先级小刘杨工如果面试问接口慢怎么排查我按什么顺序说我按命中率排序这样说最稳慢 SQL索引失效 / 数据量增长——超过一半的慢接口都栽在这先EXPLAIN。缓存失效或击穿——请求穿透到 DB查缓存策略和热点 key。下游 RPC 慢——链路追踪看瀑布图。GC 停顿——转 Full GC 排查流程。锁竞争——jstack看线程阻塞。线程池排队——查线程池配置和下游响应时间。记住先说最常见的再展开面试官会觉得你实战经验丰富。常态防御——收尾必说小刘修好了就完了我当然不。收尾一定要说常态防御这是加分项开启慢查询日志SET long_query_time 1;定期用mysqldumpslow -s t -t 10出 TOP 10 慢 SQL主动优化。配合压测和缓存预热防复发。核心接口加监控告警RT 超过阈值自动通知。尾声修复上线后/order/detail接口的 P99 延迟回到了 180ms。小刘杨工今天学到的东西够我吹半年面试了。我记住排查接口慢就像破案链路追踪缩小范围→服务层排除资源问题→SQL 执行计划定位根因。套路熟了线上就不慌了。他点点头补了一句还有以后写 SQL 我一定先EXPLAIN再上线。我笑了这才是今晚最大的收获。c