大促前做慢接口专项治理，核心清单只有四件事：全链路排查、分级分类优化、压测验证、预案演练，按这个顺序做透，线上基本能稳住。
为什么大促前必须把慢接口单独拎出来治理
平时接口慢一点,用户可能刷新两下就过去了，大促不一样，流量是平时的几十倍，慢接口会像堵车一样连锁反应，一个订单接口慢500毫秒，用户等不及就退款，退款又触发另一个接口，慢慢把整个系统拖垮，行业共识是，大促期间80%的故障根因都能追溯到性能瓶颈，而其中慢接口占相当一部分。
很多团队平时不重视慢接口,觉得机器能扛，但大促是流量洪峰，慢接口会快速积压线程池，把CPU、内存打满，最后服务雪崩，你看往年大促出现白屏、超时，基本都是慢接口没提前收拾干净。
所以大促前一个月,必须拿出一份可执行的慢接口治理清单，按优先级逐项过，这份清单不是写给人看的，是拿来打勾的。
慢接口治理清单的第一步：把家底摸清楚
建立慢接口清单，不能只靠监控告警
你所在的公司肯定有APM或者链路追踪系统,但监控只能告诉你哪个接口慢，不能告诉你为什么慢，第一步是拉出最近一个月所有接口的平均耗时、TP99、TP999数据，把超过预设阈值的接口全部列出来，阈值怎么定？可以参考历史大促的峰值表现，但更实用的办法是：凡是TP99大于500毫秒的写接口、大于300毫秒的读接口，都列为重点观察对象。
按业务影响度和调用量排序
慢接口清单不是一次拉完就完了,要按影响面排序，排序规则很简单：
- 大促主流程涉及的下单、支付、库存扣减接口排第一位
- 用户核心路径上的商品详情、购物车、优惠券计算排第二位
- 非核心但调用量巨大的异步通知、日志上报排第三位
- 内部管理后台接口虽然慢,但影响小，可以放最后
这一步的目的是,别把精力耗在一年没人调用的冷门接口上，大促前治理慢接口，要像给房子做消防检查一样，先查卧室和厨房，储藏室最后看。
拆分慢接口的调用链，找到真正的耗时点
有了清单和排序,接下来要逐个拆调用链，比如一个商品详情接口慢，可能是Redis慢，可能是下游商品服务慢，也可能是本地做了太多序列化，用链路追踪工具，把一次请求的每个Span耗时拉出来，找出占比最大的那个环节，这里有个实用技巧：如果耗时集中在某个外部依赖，先看超时时间设置是否合理；如果集中在自身代码，再看是否有重复查询、循环调用。
这一步要产出一个明细表,字段包括：接口名、调用量、TP99、瓶颈环节、初步判断，后续所有优化都围绕这个表展开。
慢接口治理的核心动作：分类治理，别一把抓
慢SQL是头号敌人，用explain和慢查询日志定位
行业专家指出,大促场景下慢接口有相当比例是慢SQL导致的，排查慢SQL不复杂，两步走：先打开数据库慢查询日志，把执行时间超过1秒的SQL捞出来；再用explain看执行计划，重点看是否走了全表扫描、索引失效、临时表排序。
常见的优化手段：加联合索引、改写SQL避免函数包裹索引列、分页查询改小范围、复杂统计提前跑批，如果单表数据量超过千万，优先考虑分库分表，但大促前不建议做大的表结构变更，风险太高。临时方案是加缓存，把热点数据提前预热到Redis，让压力在缓存层消化掉一部分。
外部依赖慢：超时、重试、降级一个都不能少
接口慢也可能是下游服务慢,比如你调订单服务的一个接口，下游因为自身问题耗了2秒，你的接口跟着慢，针对这种，清单里要明确三项配置调整：
- 超时时间：普通接口建议设置300-500毫秒，核心接口可以放宽到800毫秒，但绝不能没有超时
- 重试次数：只对幂等接口允许重试，且最多重试一次，重试间隔要随机化，防止启动雪崩
- 降级开关：给关键依赖配置降级逻辑，比如缓存降级、默认值降级、静态数据降级
大促前要一个一个依赖确认,别等到线上才调，你可以模拟下游故障，看看降级能不能生效，这个动作在压测环节会反复做。
代码逻辑慢：拆循环、去重复、抓内存分配
有些慢接口是自己代码写的烂,比如在for循环里查数据库，或者反复新建大对象，这类问题用代码审查或者profile工具就能抓出来，处理方式很直接：
- 循环内查询改成批量查询,一次查出所有需要的数据
- 重复调用同一数据源改成局部变量缓存
- JSON序列化改用更高效的序列化框架,比如Kryo
- 大对象复用,避免频繁GC
这类优化见效快,但需要开发人员逐行看代码，建议每个服务负责人自己认领接口，别指望别人替你看。
线程池和连接池参数：大促前的必调项
很多慢接口不是代码慢,是线程池满了，新的请求在排队等待，Tomcat线程池、数据库连接池、HTTP客户端连接池都要检查，大促前调整参数有讲究：线程池不是越大越好，要结合CPU核数和下游承受能力。一般建议把核心线程数设置为CPU核数的2倍，最大线程数设置为核数的4倍，队列容量给到合适的值，数据库连接池同理，压测时观察活跃连接数，别拼命往上加。
大促前慢接口治理的验证环节：压测和预案
压测别只看平均耗时，要盯TP99和错误率
优化完一批接口后,必须用压测来验证，压测场景要模拟大促的真实流量特征，包括：峰值QPS是平时的多少倍、读写比例、热点数据集中程度，压测过程中看几个关键指标：
- TP99是否在目标范围内,比如下单接口不超过800毫秒
- 错误率是否为零,允许少量超时但不能有5xx
- CPU和内存使用率是否在安全水位,一般CPU不超过70%，老年代GC频率不能太高
如果压测不通过,回到分类治理的清单重新排查，别硬扛。
预案演练：慢接口问题要能自动恢复
大促前最后一步,是给慢接口准备一套应急预案，预案不是文档，是能自动执行的，至少要有以下两类操作：
- 针对某个慢接口的限流规则,比如当TP99超过2秒时，自动拒绝非核心流量
- 针对慢依赖的熔断规则,比如错误率达到阈值直接熔断，后续请求走降级逻辑
演练的时候,人为把某个接口调慢，观察监控是否触发、预案是否生效、业务是否受影响。整个演练过程要录屏留档，大促当天按同样的步骤做一次快速检核。
这套验证做完,慢接口治理清单才算闭环：发现、定位、优化、验证、预案，缺任何一环，大促当天都可能出问题。
慢接口在大促前的专项治理清单常见问题
问：大促前只优化慢接口够吗？要不要做全链路压测？
不够,慢接口治理是基础，全链路压测是更高一个量级的验证，治理慢接口解决的是"接口本身不慢"的问题，压测解决的是"整体扛不扛得住"的问题，建议先完成本清单里的所有优化，再做针对性的全链路压测，如果压测发现新的慢点，再回到清单里补充治理。
问：对于慢SQL优化，大促前不适合做表结构变更，那索引可以用吗？
可以用,但要谨慎，新增索引属于DDL操作，在MySQL 5.6以上版本支持在线DDL，不会锁表，但如果数据量大，执行期间可能有一定IO开销，大促前建议在业务低峰期执行，并且先在预发环境验证索引效果，如果优化效果不理想，宁可先加缓存顶着，别临时调整核心表结构。
问：外部依赖超时时间设置成多少比较合适？
没有统一数字,要依赖的实际调用链来定，一般建议核心链路的外部依赖超时控制在200-500毫秒，非核心依赖可以放宽到1秒，但要注意，超时设置太短会导致频繁触发熔断，设置太长又等于没设，业内通用的做法是：先压测出该依赖的TP99，把超时设置为TP99的3倍以上，再结合业务容忍度调整，最终目标是不让外部依赖拖垮你的接口。