接口性能优化实战指南：从慢SQL到缓存穿透的完整打法

前两天群里有人甩了一道面经出来：“京东一面：接口性能优化，有哪些经验和手段”。我第一反应是，这面试官问得挺实在。接口性能优化这个事，做没做过、踩没踩过坑，聊几句就能听出来。你要是能把一条线上接口从几百毫秒优化到几十毫秒，再顺手平掉一次缓存穿透事故，基本就能证明你是真写过生产代码的人。

这篇文章我把这些年做接口性能优化的完整打法整理了一遍，从定位问题、数据库层、缓存层、应用层再到高并发治理，每个环节都给到可以直接用的套路。不管你是准备面试，还是线上接口突然告警了来找方案，应该都用得上。

1. 先定位再动手：性能优化第一步不是改代码

1.1 先把“慢”量化：RT、TP99、QPS这些指标到底怎么看

接到一个性能问题，第一步不是急着开代码，而是先把现状量化清楚。你连接口到底有多慢、慢在哪个环节都不知道，动手改就是盲人摸象。我见过有人把 SQL 改了十几版，最后发现慢的原因是下游第三方接口超时时间设成了 60 秒，每次都在那儿傻等，跟数据库一点关系都没有。

最基础的两个数是平均响应时间和吞吐量，但真正要盯的是分位线。平均 RT 你看着可能还行，比如 500ms，但 TP99 可能已经到 3 秒了。为什么？因为那 1% 的慢请求才是用户真正感知到的卡顿，而它们会被绝大多数正常请求平均掉。所以线上监控必须分开看 TP50、TP90、TP99、TP999，尤其 TP99 以上，才是性能优化要重点照顾的对象。

另一个容易忽略的是 QPS 和线程利用率。一个接口 RT 从 500ms 降到 100ms，表面上看是用户变快了，但这不只是用户体验问题，背后是同样的资源能扛住的并发量翻了接近 5 倍。所以记指标的时候，要把优化前后的 RT、QPS、错误率、服务器负载放在一起去对比，缺了哪一项，这个优化效果都是不完整的。

1.2 找出慢在哪一环：全链路追踪把接口拆开看

定位问题最直接的手段是全链路追踪。现在基本都有现成方案，开源的有 SkyWalking、Pinpoint，商业的有各种 APM 产品。一次请求从网关到应用再到数据库、Redis、下游 RPC，每一步耗时都能在调用链里看到，慢在哪一层清清楚楚，不用靠猜。

如果没有完整的链路追踪，也可以用 Arthas 的 trace 命令，在接口入口处看方法内部的耗时分布。我一般按这个顺序排查：先看是不是慢 SQL，再看缓存有没有问题，再看外部 RPC 是不是超时了，最后才查 GC 和线程池。为什么这个顺序？因为数据库和 Redis 是接口最常碰的资源，出问题的概率最大；外部 RPC 是接口自己控制不住的，最容易出玄学问题；GC 和线程池的问题相对隐蔽，但往往后果最严重。

1.3 建立性能基线：没有对比就没有优化

优化之前，一定要先把当前版本的性能基线打出来。我在项目里会把压测脚本固化下来，常用 JMeter 做完整的场景压测，也会用 wrk 做单接口快速验证。关键一点：压测环境的数据量和数据分布要尽量贴近生产。你用一个几百条数据的库压出来的结果，跟生产上几千万行数据完全不是一回事，压出来的数字只能自欺欺人。

每次发布完性能相关的改动，手上要有优化前的数据和优化后的数据对比。我自己有个习惯，每次优化前会把当时的 TP99、CPU、慢 SQL 数量截图存档，优化完再截一次图，时间久了就攒成自己的案例库。面试的时候，你说“有个接口 TP99 从 800ms 优化到 120ms”，跟你空口讲“我做过性能优化”，可信度完全不一样。

2. 数据库层优化：八成慢接口的根子在 SQL

2.1 慢 SQL 怎么查：慢查询日志加 EXPLAIN

数据库层的坑我踩得最多。说实话，大多数接口慢，根子就是 SQL 写得有问题，或者建表的时候索引没设计好。所以第一步永远是先看慢查询日志。

MySQL 的慢查询日志配置很简单，在 my.cnf 里加几行：

ini复制slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 1
log_queries_not_using_indexes = 1

long_query_time 设为 1 秒，超过 1 秒的 SQL 都会被记下来。线上排查的时候，先看一眼慢日志里哪些 SQL 出现频率高、单次执行时间长，八成问题就浮出水面了。

拿到慢 SQL 之后，用 EXPLAIN 分析执行计划。重点看几列：type 是 ALL、index、range、ref 还是 const，ALL 代表全表扫描，是性能最差的情况；key 看实际用到的索引；rows 看预估扫描行数；Extra 里出现 Using filesort 或 Using temporary 就要注意排序和临时表的问题。一个典型的优化就是让 type 从 ALL 变成 range 或 ref，rows 从几十万变成几百几千，SQL 的执行时间往往立刻就能降下来。

2.2 索引优化：联合索引、覆盖索引与索引失效

说完怎么找慢 SQL，再说索引怎么建。索引不是越多越好，但该建的时候一定不能省。如果 EXPLAIN 显示全表扫描，最直接的方案就是建一个合适的索引。

有几个场景特别容易踩坑，我一个个说。

函数导致索引失效。比如 WHERE DATE(create_time) = '2024-01-01'，你对 create_time 用了函数，索引就失效了，因为索引里存的是原始值，不是函数处理后的值。正确写法是 create_time >= '2024-01-01 00:00:00' AND create_time < '2024-01-02 00:00:00'，让索引能直接走范围查找。

隐式类型转换。字段是 varchar 类型，查询条件用了数字，MySQL 会先把字段转成数字再比较，索引同样失效。所以写代码的时候，参数类型和数据表字段类型必须严格对齐。

LIKE 左模糊。LIKE '%xxx' 这种写法，因为没法利用索引的有序性，只能全表扫描。真要支持这种搜索，要么考虑搜索引擎，要么换个思路用前缀匹配。

联合索引要注意最左前缀原则。举个实例：建了索引 (a, b, c)，查询条件只带 a 能走索引，带 a 和 b 能走索引，带 a、b、c 也能走索引，但只带 b 或者只带 c 就走不了。所以联合索引的字段顺序很重要，最常用的等值条件放最左边。

覆盖索引是个性价比很高的优化。如果查询需要的列都包含在索引里，MySQL 就不用回表查整行数据。比如你要查用户的 uid 和 status，而索引刚好是 (uid, status)，那直接扫索引就能返回结果，省掉一次回表，在高频查询场景下收益非常明显。

2.3 深分页与查询改写：别让数据库做多余的事

分页查询的深分页问题也是重灾区。LIMIT 100000, 20 这种写法，看着是查 20 条，实际上 MySQL 先把前面十万条全都查出来，再全部丢掉，前面十万条全是无用功。

一个暴力但有效的优化是延迟关联。先让子查询用覆盖索引快速定位到需要的主键 id，再回原表关联取数据：

sql复制SELECT o.* FROM orders o
INNER JOIN (SELECT id FROM orders ORDER BY id LIMIT 100000, 20) tmp
ON o.id = tmp.id;

子查询里只查了 id，走的还是主键索引，扫描成本比直接 SELECT * 低很多。更好的做法是改成基于游标的分页，也就是 where id > 上一页最大id order by id limit 20，这种方式数据量大以后依然稳定，是目前最推荐的分页方案，但只适合按主键排序的场景。

还有一个高频问题是 N+1 查询。很多接口里有个循环，每次循环查一次数据库，几十个用户就发了几十次数据库请求。解决办法很简单，循环外先批量查出来，再在内存里做组装。批量查询的 IN 条件数量要控制一下，一次几百个问题不大，但别一次塞几千上万个 id，SQL 本身的解析和网络传输也会变成压力。

另外，SELECT * 这种写法我基本不让出现在线上代码里。表结构一旦变更，SELECT * 不仅会查出不需要的字段，可能还导致覆盖索引失效，白白增加传输开销和临时表空间。

2.4 连接池与数据库架构：调参和分库分表的时机

数据库连接池也值得调。HikariCP 默认最大连接数是 10，很多人一上来就调到 200，想着越多越好，结果反而更慢。数据库连接不是免费的，每次建立连接都要握手认证，连接太多还会让数据库端线程调度和内存开销飙升。IO 密集型应用，我一般从 CPU 核心数乘 2 加 1 这个值起步，也就是 core * 2 + 1，再看压测结果微调，不要拍脑袋。

再往上走就是架构层面的事了。读写分离可以早做，把报表、统计类的读流量打到从库，减轻主库压力。分库分表我建议谨慎，先把索引、缓存、SQL 都优化到位了，数据量真的到单表几千万、写入 QPS 压不住一个主库的时候再考虑。很多团队连慢 SQL 都没处理干净就开始分库分表，结果分布式事务、跨库 join 这些问题把系统复杂度直接翻倍，得不偿失。

3. 缓存优化：读多写少接口的最强加速器

3.1 缓存选型：Caffeine 本地缓存与 Redis 分布式缓存怎么搭档

数据库优化完之后还不满意，下一步就是上缓存。缓存是读多写少接口的加速神器，但选型要想清楚。

本地缓存，比如 Caffeine，读取速度最快，没有网络开销，但每个服务实例各存一份，数据一致性要靠业务自己兜。Redis 是分布式缓存，所有实例共享同一份数据，一致性有保障，但每次读多一次网络往返。我的一般原则是：优先用 Redis，只有数据几乎不变、并且服务实例不会在短期内频繁重启的场景，才在 Redis 前面再加一层本地缓存做二级缓存。

二级缓存的坑在于更新机制。如果本地缓存靠定时任务刷新，所有实例大概率同时触发刷新，就会瞬间出现局部击穿。我自己的做法是给每个实例的刷新时间加随机扰动，别让它们同时去拉数据。另外，本地缓存过期之后，所有实例同时回源 Redis 或数据库，也可能造成短暂压力尖峰，这个要有心理准备。

3.2 缓存穿透、击穿、雪崩：三个经典事故和对应解药

缓存这个环节，穿透、击穿、雪崩是绕不开的三个问题，面试爱问，线上更是真实发生过无数次。

缓存穿透是指查询一个根本不存在的数据。恶意请求拿不存在的 id 刷接口，缓存查不到，数据库也查不到，每次请求都会打到 DB。如果量一大，数据库直接被压垮。解决办法有俩：一是缓存空值，查不到数据也 set 一个空值，加个很短的过期时间，比如 60 秒；二是用布隆过滤器，在请求进缓存之前就先判断 key 是否存在，不存在直接拦掉。布隆过滤器有个特点，它只会误判“可能存在”，不会漏判“一定不存在”，所以对拦截穿透有奇效，但删除操作不友好，实际使用中我一般两个方案叠加。

缓存击穿是指一个热点 key 在过期的那一瞬间，大量请求同时打到了数据库。一个热卖商品的缓存刚好过期，几千个请求同时发现缓存没有，全冲进 DB。解决办法是互斥锁重建缓存，拿到锁的线程去查库回填，其他线程先等着或者返回旧值。伪代码大概是这样的：

java复制public String get(String key) {
    String value = redis.get(key);
    if (value != null) {
        return value;
    }
    String lockKey = "lock:" + key;
    boolean lock = redis.setIfAbsent(lockKey, "1", 3, TimeUnit.SECONDS);
    if (lock) {
        try {
            value = db.query();
            redis.set(key, value, expireTime);
            return value;
        } finally {
            redis.delete(lockKey);
        }
    }
    Thread.sleep(50);
    return redis.get(key);
}

缓存雪崩是指大量 key 在同一时间集体过期。解决起来最省事也最有效：过期时间加随机值。比如原本所有 key 都是 3600 秒，现在在 3600 到 4200 之间随机取一个值，打散过期时间，从根上避免大面积同时失效。

3.3 缓存更新策略：先更库还是先删缓存

缓存和数据的一致性是个老生常谈的问题。默认推荐 Cache Aside 模式：读的时候先读缓存，读不到就读 DB，然后回填缓存；写的时候先更新 DB，再删除缓存。注意是删除，不是更新缓存。因为更新缓存要考虑并发下其他线程可能已经把新值写进去了，你一覆盖反而把新值弄丢了；删掉缓存，等下次读的时候再回填，逻辑最简单。

这里有一个非常经典的坑。很多人图省事，先删缓存再更新 DB，并发场景下会出大问题：删完缓存，DB 还没更新，另一个线程来了，读 DB 拿到老数据回填缓存，缓存里就长期存着旧数据。为了解决这个问题，有人搞了延迟双删，先删缓存、更新 DB、再延迟几百毫秒删一次缓存。但延迟时间很难定，而且第二次删除也可能失败。

我自己更推荐先更新 DB 再删缓存，同时用订阅 binlog 的方式做补偿。比如用 Canal 监听 DB 的变更事件，异步把缓存删掉，删除失败就丢到消息队列重试。成本高一点，但一致性可控得多。缓存一致性没有银弹，最终还是要根据业务对数据新鲜度的容忍度来选方案。

3.4 过期时间、热点 Key 与大 Key：容易被忽略的细节

缓存参数设计里，最容易忽略的是过期时间。过期时间设置的唯一原则是：业务对数据新鲜度的容忍上限。用户昵称 5 分钟不更新用户能接受，那就设 300 秒；库存数量 1 秒不能错，那就不该走普通缓存。任何缓存 key 的过期时间都不要写死在代码里，放到配置中心，随时能动态调整。

热点 Key 也是生产环境的高发问题。某个 key 在秒杀期间被几万请求同时读，一个 Redis 节点扛不住，接口照样慢。常用解法是给热 key 加随机后缀，拆成多个 key 分散到不同的 Redis 节点。比如 hot:item:1 拆成 hot:item:1:001、hot:item:1:002 这些，每个 key 都存同样的数据，读的时候随机选一个。本地缓存也是一个兜底方案。

大 Key 也要当心。一个 key 的 value 到了几百 KB 甚至几 MB，读写都占用很大的带宽和内存，还会阻塞 Redis 的单线程处理。我在线上排查过一个大 key，value 里塞了几千个元素的列表，每次读取几十毫秒，高峰期直接把 Redis CPU 拉满。解决思路要么拆成多个小 key，要么改用 hash 结构存储，要么压缩 value。生产环境建议定期扫描，用 redis-cli 的 --bigkeys 参数跑一把，把大 key 揪出来处理掉。

4. 应用层优化：代码里省下的每一毫秒都算数

4.1 用并行调用压缩 RT：CompletableFuture 与线程池参数计算

数据库和缓存层面都优化完，接口可能还是慢。这时候要看看代码层面是不是还有不少浪费。

最常见的问题是串行调用。很多查询接口要拼装数据，先查订单，再查用户，再查营销信息，三次远程调用串行执行，假设每次 50ms，加起来就是 150ms。但这些调用彼此独立，完全可以并行。用 CompletableFuture 改造成本很低：

java复制ExecutorService pool = new ThreadPoolExecutor(
        8, 16, 60L, TimeUnit.SECONDS,
        new ArrayBlockingQueue<>(1000),
        new NamedThreadFactory("user-order-pool"),
        new ThreadPoolExecutor.CallerRunsPolicy()
);

CompletableFuture<UserInfo> userFuture = CompletableFuture.supplyAsync(
        () -> userClient.getUser(id), pool);
CompletableFuture<OrderInfo> orderFuture = CompletableFuture.supplyAsync(
        () -> orderClient.getOrder(id), pool);

CompletableFuture.allOf(userFuture, orderFuture).get(500, TimeUnit.MILLISECONDS);
UserInfo user = userFuture.getNow(null);
OrderInfo order = orderFuture.getNow(null);

所有远程调用都加上超时控制，allOf 之后再用 get 指定一个总的超时时间，防止某个下游一直不返回，把接口拖死。

线程池参数计算这里多说一句。CPU 密集型任务，线程数一般取 CPU 核心数加一。IO 密集型任务，因为大量时间在等待 IO，线程数可以更多，经验公式是 CPU 核心数乘以（1 + IO 等待时间/计算时间）。举例，8 核机器，一次任务计算 10ms，IO 等待 90ms，合理线程数就是 8 ×（1 + 90/10）= 80。但公式只是起点，最终要以压测结果为准。

并行调用也会放大下游压力。原本 100 QPS 的接口，里面并行调三个下游，下游收到的就是 300 QPS。账要提前算清楚，别优化了自己的 RT，却把下游打挂了。

4.2 批量化与请求合并：减少交互次数就是减少耗时

代码层面还有一个比较容易做的优化：把循环里的单次调用改成批量调用。

我经常在代码里看到这种写法：for 循环里查 20 次用户信息，一次接口 20 次数据库往返。改成一次 IN 查询，接口 RT 立刻大幅下降。同理，调远程服务的时候看有没有批量接口可用，有就优先用。

如果批量接口也不是很高效，可以把循环动作分成几个小批次并行执行。比如一次最多查 100 个，但你有 300 个 id，就拆成 3 个批次，用线程池并行查，再合并结果。这种方式既能控制单次请求的规模，又能压缩总耗时。

请求合并或者请求折叠，是另一个方向。它是把多个相同类型的请求合并成一个批量请求处理，适合吞吐量高、单个请求量小、对延迟不太敏感的场景，比如埋点日志上报。实现方法是搞一个队列，攒够一批或者到时间之后统一发送。但别乱用，如果业务对实时性要求很高，合并请求引入的额外延迟反而会坏事。

4.3 异步化改造：把非核心链路挪到消息队列

接口里不是所有操作都需要用户在线等。发短信、发邮件、App 推送、写审计日志、累计积分，这些都属于非核心链路。同步执行这些操作，等于让用户白白等一次网络耗时。改成投递到消息队列立刻返回，接口 RT 能降下来一大截。

异步化的代价是链路变成最终一致。消息队列投递成功了，不代表下游消费一定能成功。消费端要有重试策略，要有失败告警，关键业务还要做对账补偿。如果消费者自身处理太慢，消息堆积也会把下游打垮，所以消费端同样要做限流和削峰。

别一听说异步好就全盘异步。业务强一致、需要立即拿到结果才能继续的链路，就不要异步化。比如支付回调的校验逻辑，你异步化之后商家端可能几秒内看到的状态都是错的，这种业务不能这么玩。

4.4 小细节大影响：超时设置、序列化与日志开销

超时设置是我每次代码 review 都会盯的点。很多被拖垮的系统，根因就是下游调用超时时间设得太长，线程全部卡在等响应上。连接超时一般 1 到 2 秒，读超时按业务容忍度设，通常 3 到 5 秒以内。宁可快速失败，也不要让线程挂在那儿。还有重试，要有上限，而且别在用户请求线程里无脑重试，一旦下游已经崩溃，重试只会加重雪崩。

序列化的开销也是可以被量化的。同一个接口里频繁做 JSON 序列化和反序列化，一定要复用 ObjectMapper，不要每次 new。大对象不要重复创建，对象池或者复用是更好的选择。日志也一样，循环里打日志、大对象直接 toString 打到日志里，线上流量一大都是实打实的性能损耗，别小看。

5. 高并发下的接口治理：优化做完了，还要会“兜底”

5.1 限流、降级、熔断：为什么它们是高并发接口的标配

性能优化做到这，接口理论上已经能扛更多的并发了。但系统的性能上限终究是固定的，流量却不可预测。大促、活动、热点事件，瞬间的流量洪峰随时可能超过系统上限。如果没有限流保护，结果就是雪崩，服务彻底不可用。

所以限流、降级、熔断虽然本身不是性能优化，却是性能优化的护栏。它们不会让接口变快，但能保证系统在极限情况下依然对一部分用户正常响应，而不是全员报错。我在负责高并发接口时，这几个组件基本都是标配。

常用的方案，过去大家用 Hystrix 比较多，现在已经停止维护了。我更推荐 Sentinel 或者 Resilience4j。Sentinel 功能更全，控制台直接能看到实时的调用流量和限流效果；Resilience4j 更轻量，适合只想引入熔断、限流、重试等基础能力的项目。

5.2 限流阈值怎么估算：什么时候该给接口加保护

限流阈值不是拍脑袋定的，要做换算。简单估算方法：单机可承受 QPS = 核心线程数 ×（1000ms / 平均接口耗时），再乘以服务实例数，然后留出 20% 到 30% 的冗余做保护。比如单机极限 1000 QPS，10 台实例，集群理论上限 10000，那限流值我会先设到 7000 左右，后续根据压测慢慢调。

限流算法上，固定窗口实现简单但有临界突刺问题，滑动窗口更平滑。令牌桶允许一定的突发流量，适合电商大促这种场景；漏桶是严格控制处理速率，适合对流量平滑度要求高的系统。单机限流可以直接用 Guava 的 RateLimiter，分布式限流要用 Redis 加 Lua 脚本，或者直接用 Sentinel 这种带集群限流的组件。

5.3 熔断与隔离实战：别让一个慢接口拖垮整个应用

熔断机制的核心是：当下游服务持续出错或超时，熔断器打开，后续请求快速失败，不再继续调用已经出问题的下游。等一段时间后，放少量请求过去探测，如果恢复了就关闭熔断器，否则继续打开。阈值一般这么设：连续 N 个请求失败，或者错误率超过 50%，或者慢调用比例超过一定值，具体数值要根据下游的容忍度压测后确定。

隔离是容易被忽略的一环。线程池隔离指的是把慢接口、高风险的下游调用放到独立的线程池里，不让它们占用 Tomcat 的业务线程。我用信号量隔离也解决过类似问题，它不依赖线程池，只是限制并发调用数，适合非阻塞的调用。实际遇到过的情况：一个第三方回调接口处理特别慢，和普通查询业务共用一个线程池，结果第三方一抖动，整个应用的所有接口全部卡死。把回调接口单独拆到独立线程池之后，其他接口再也没被拖累过。

6. 常见问题排查与实战经验

6.1 一次偶发性超时问题排查实录

分享一个我之前调过的真实问题。现象是线上某个查询接口 TP99 一直偏高，但平均 RT 还算正常。高峰期偶尔有服务超时告警，低峰期一切正常。

排查步骤我一步步说。先看了调用链，耗时主要集中在 service 层的一个查询方法。然后查慢 SQL，慢日志里没有明显超长的语句。接着看 Redis 监控，发现有一个大 key，每次读取要几十毫秒，但离 2 秒还差得远，不够解释 TP99 为什么冲到 2 秒。

后来用 jstat 看了下 GC 情况，发现 Full GC 非常频繁，每次停顿几百毫秒。再看堆内存，对象在新生代疯狂创建、瞬间晋升到老年代。最后定位到代码里有个高频方法，每次调用都 new 了一个 ObjectMapper，并发一高，堆里全是这种大对象，频繁触发 Full GC。

修复方式很简单，把 ObjectMapper 改成单例复用，对象分配速率降下来，Full GC 基本消失，TP99 从 2 秒降到了 300ms 左右。这个案例给我的教训是：性能问题有时候跟 SQL、缓存都没关系，JVM 层的偶发 GC 停顿反而最隐蔽，排查的时候一定不能漏。

6.2 高频坑位速查表

我整理了一张高频性能问题的速查表，适合线上告警时快速对照：

这张表不是万能的，但它能帮你快速圈定方向。遇到问题先按表里的方向排查，比漫无目的地翻代码有效率得多。

6.3 如何向面试官证明你懂性能优化

如果你正在准备面试，这道题最好的答法不是背清单，而是给一条清晰的主线：先量化指标，再定位瓶颈，然后针对性地优化，最后用压测验证。你把这条主线的逻辑讲清楚，面试官就知道你不是死记硬背。

然后挑一个自己真实做过的案例讲细节。我遇到过那种能精确说出“当时有个 SQL 全表扫描，扫描了 80 万行，加了一个联合索引之后 rows 降到 500，接口从 800ms 降到 150ms”的候选人，和只会罗列的候选人，高下立判。所以平时优化的时候，把数据留好，这些都是你以后面试和晋升时的硬通货。

我的个人习惯是每次优化前先写清楚目标指标，优化后把压测结果和监控截图存档。坚持一段时间你会发现，这些真实案例比任何面经都值钱。技术面试问到性能优化，你随便抽一个案例都能讲得有细节、有数字、有取舍，这比背一百条理论有用得多。