项目里的慢接口如何优化？

核心回答

慢接口优化的主线是：先确定慢的表现和业务目标，再通过链路数据找主要耗时，对准瓶颈修改，最后在相同条件下验证收益与代价。 常见手段包括 SQL 与批量查询优化、减少重复计算、缓存、有限并行和非关键任务异步化，具体选择取决于慢在哪里。

可以按下面的顺序展开：

1. 建立基线：明确接口用途、数据规模、请求量，区分客户端总耗时与服务端处理时间，同时看 P50、P95/P99、错误率、超时率和资源水位。
2. 分段定位：把请求关联到数据库查询、外部调用、线程或连接池等待、锁等待、计算和响应序列化，找出决定完成时间的主要路径。
3. 针对性修改：扫描多就改查询和索引，重复调用多就批量或复用，独立 I/O 串行就评估有限并行，排队严重就检查容量和背压。
4. 保持业务语义：返回更早、缓存旧值或缺少某些字段，都会改变用户拿到的结果，需要明确哪些结果必须同步完成。
5. 同条件复测：比较延迟分布、成功吞吐量、下游负载和业务完成情况，再观察真实流量下的表现。

怎样判断真正卡在哪里？

先用同一个请求 ID 串起日志，条件允许时查看调用链和分段计时。接口慢，不代表某一条 SQL 一定慢：可能是很多条很快的 SQL 被循环调用，也可能只是拿数据库连接时排队。

如果数据库执行占比高，再结合慢 SQL、执行计划、扫描行数和锁等待定位；如果主要是应用计算，再看 CPU 采样、线程状态和 GC 停顿；如果主要是外部调用，则拆开连接建立、请求等待、重试和连接池等待。

调用链中的父子耗时可能重叠，独立调用也可能并行，不能把所有耗时直接相加。需要沿请求完成所依赖的路径判断：减少一段不影响最终完成时间的工作，未必能缩短接口响应。

订单列表接口的参考方案

假设接口要展示一页订单及商品、物流摘要。链路分析发现：查完订单后，逐条查询商品；物流摘要和其他独立展示信息又串行调用。此时可以这样改：

• 先消除逐条查询：拿到本页订单后，将商品 ID 去重并批量查询，再在内存中按 ID 组装，减少数据库往返。若订单主查询本身扫描过多，再根据用户、状态、时间和排序需求评估联合索引。
• 再并行独立调用：只有拿到必要订单信息后，才能发起依赖这些信息的请求；彼此无依赖的展示调用可有限并行，并设置总超时预算、并发上限及允许的部分失败处理。不能把每一行都无限制地提交给下游。
• 按数据性质决定是否缓存：变化较少、允许短暂陈旧的商品展示信息可评估缓存，同时明确键的用户或租户范围、TTL、更新失效与回源能力。实时价格、权限或订单状态不能直接套用同一策略。
• 只移走允许后置的工作：统计上报等附属任务可以后置；需要可靠完成的任务应持久保存、可重试并具备幂等处理，不能只开个后台线程就认为已完成。

这个方案分别减少重复往返、缩短独立 I/O 的等待路径；收益还要用实际数据验证。如果下游已经饱和，并行反而可能增加排队，此时需要先控制负载。

如何说明优化效果？

前后比较应尽量保持机器规格、数据量、请求组合、负载和缓存状态一致，既测常见请求，也覆盖未命中缓存、大用户和高峰压力等情况。延迟应结合错误和超时统计，避免大量快速失败把平均耗时拉低。

除了端到端 P95/P99，还要看数据库调用次数与扫描量、外部调用耗时、连接池等待、CPU/GC、队列积压等是否按预期变化。上线后可逐步放量观察，并保留回退方式；业务收益则用相应的完成率、超时减少或用户行为数据验证。

常见追问

加大线程池或连接池可以解决吗？ 如果瓶颈是下游数据库或远程服务的容量，增大池可能只会增加竞争和排队。要看等待发生在哪里、下游还有多少余量，再调整并发、队列和限流。

超时就多重试几次呢？ 重试会消耗额外资源，过载时可能把问题放大。应按总耗时预算限制次数，配合退避和抖动；有副作用的调用还要考虑幂等，超时也不等于远端没有执行。

异步或流式返回更快，算业务完成更快吗？ 需要分别测量。返回任务号或首条进度只说明已经受理或开始输出；任务完成、落库和最终结果可用还需要独立的时间点与成功状态。

对应教程

参考资料