数据库的慢查询日志往往最能说明问题。如果你发现某个接口的耗时与数据量成正比或者随着业务增长越来越慢第一步就该去看它执行的SQL。我见过很多接口优化案例最终都归结为一条走了全表扫描的SQL。用EXPLAIN查看执行计划时重点看type列——如果出现ALL意味着系统正在把整张表搬进内存这比任何代码层面的问题都致命。索引不是越多越好而是越精准越好联合索引的字段顺序、最左前缀原则、覆盖索引的利用这些细节决定了查询是走索引还是回表。另外别忽略隐式类型转换和函数包裹字段它们会让索引彻底失效。还有一个常见的坑是SELECT 。很多接口只需要两三个字段却把几十列全部查出来不仅增大了IO开销还让MySQL无法使用覆盖索引。优化的方向应该是只查需要的列并让索引覆盖这些列。判断一个查询是否高效先看它能不能用上索引再看它回表了几次。如果发现慢SQL已经存在不要急于加索引先看这个查询的频率和成本高频低成本的查询比低频高成本的查询更值得优化。同时注意分页偏移量过大的问题经典的LIMIT 100000, 20会让数据库把前十万行都扫一遍。用基于游标的分页或者记录上次最大ID效果立竿见影。我之前接手过一个列表接口数据量只有五万条但接口耗时超过三秒。排查后发现查询里对日期字段用了DATE_FORMAT函数导致索引失效。改成范围查询后耗时降到几十毫秒。大多数慢接口不是被复杂业务拖垮的而是被一条不合格的SQL拖垮的。所以排查性能问题的顺序永远先看数据库再看业务代码。缓存是最容易上手也最容易出错的优化手段。很多人喜欢在接口里直接查缓存查不到就去查数据库然后回填缓存。这个流程看似没有问题但深入到并发场景里就漏洞百出。缓存是用来扛高并发的不是用来绕开数据库的。如果缓存本身就是热点接口的瓶颈那么缓存击穿会让数据库瞬间收到大量请求。Redis的SETNX加锁回填可以解决击穿但要注意锁的粒度。穿透问题则是缓存和数据库都没有数据恶意请求可以直接绕过缓存打到数据库解决方式是布隆过滤器或者缓存空对象。雪崩问题更棘手大量key同时失效会让数据库承受流量洪峰给过期时间加一个随机值能让失效时间均匀分布。缓存另一个绕不开的问题是数据一致性。很多团队选择先删缓存再更新数据库或者先更新数据库再删除缓存无论哪种顺序都存在窗口期。用缓存提升性能是需要支付一致性的代价的你要明确这个接口能否接受短暂的数据滞后。如果业务要求强一致就不要用缓存或者引入canal监听binlog异步更新缓存。性能优化不是单纯加一层Redis而是要设计好缓存的粒度、淘汰策略和过期时间。另外缓存value的序列化格式也很关键JSON比JDK序列化体积小得多压缩后能显著减少网络传输时间。我见过不少接口已经加了缓存但命中率很低。原因要么是key设计不合理粒度太细导致缓存频繁失效要么是缓存时间太短数据刚被set进去还没读几次就过期了。判断缓存是否有效先看命中率低于80%的缓存配置大概率是错的。优化缓存时把热点数据单独设置更长的过期时间把非热点数据交给Redis的LRU策略淘汰这样能让缓存真正做到扛压。第三个值得深挖的地方是外部依赖。现代后端接口几乎不会只依赖一个数据库它可能调用了第三方支付、短信服务、ERP系统或者另一个微服务的接口。当接口耗时变长时很多人习惯盯着自己的代码和数据库却忽略了那些远程调用。每一个外部调用都是一次潜在的故障源它们有各自的超时时间、限流策略和故障模式。如果一个接口串行调用了三个外部服务每次耗时200毫秒总耗时就是600毫秒加自身逻辑。优化思路很简单把无依赖关系的调用改成并行用CompletableFuture.allOf等待所有结果可以让总耗时降低到最长的那次调用。但并行不是万能的。如果你的系统线程池只有10个线程每来一个请求就占用3个线程去做并行调用那么10个并发请求就能把线程池打满后续请求全部排队。并行化之前先评估线程池的容量和拒绝策略否则不仅没提速还会拖垮整个应用。外部调用还必须设置合理的超时时间。很多团队默认用框架的3秒超时但接口内部又设置了重试一个请求可能因为重试而等待9秒。超时时间要根据业务容忍度来定建议按等级划分读操作500毫秒写操作1秒超过就熔断。熔断器要配合降级策略返回兜底数据而不是把异常抛给前端。另外外部调用的连接管理也很容易被忽视。HTTP连接池太小会导致TCP握手频繁连接池太大又会占用过多文件描述符。优化外部依赖的核心原则是缩短链路、降低等待、快速失败。能批量调用的不要循环调用能异步的不要同步阻塞能本地缓存的不要远程获取。把这些做扎实接口的性能会有质的提升。线程池和连接池是后端接口的性能水面下的冰山。很多接口本身逻辑很轻但依然响应缓慢此时就要怀疑共享线程池是否被打满。常见的业务线程池如果使用默认配置核心线程数太小队列容量过大会导致请求长时间排队。线程池的大小要与业务的IO比例匹配纯CPU计算型线程数设为CPU核数1IO密集型可以设为核数乘以2或者更高但真正靠谱的做法是通过压测找到最优值。连接池同理数据库连接池配置为20并不意味着性能最好它只代表能同时执行的数据库查询数量。当连接池被占满新的查询必须等待空闲连接这时候接口耗时会急剧上升。网上有许多关于连接池大小的黄金规则比如DBCP、C3P0、HikariCP的配置中一个经典的公式是connections ((core_count 2) effective_spindle_count)。但这个公式不一定适用现代云服务器。盲目调大连接池并不能解决慢查询只会加剧数据库压力。如果你的数据库查询本身已经很快了连接池持有时间很短那么几个连接就足够支撑高并发。真正的性能瓶颈往往不是连接不够而是连接被某些慢SQL长时间占用。优化连接池参数前先确保没有慢查询抢占资源。线程池还需要警惕另一个问题线程上下文切换。当线程数远超CPU核数时大量的时间会花在切换而非执行上。我碰到过一个接口压测时发现增加线程数后吞吐量反而下降原因就是上下文切换消耗了过多资源。线程不是越多越好性能拐点出现在线程数接近CPU核数的某个倍数时。排查这类问题可以关注GC日志和线程dump看看是否有大量线程处于BLOCKED或WAITING状态。另外异步化不是银弹。把耗时操作丢到异步线程池后接口虽然立刻返回了但异步任务可能会积压。如果异步线程池没有设置拒绝策略和监控系统会在某一天突然崩溃。连接池和线程池的调优本质上是在榨干资源的同时守住系统的稳定性边界。最后一个优先级极高但往往被忽略的地方是接口的返回数据。后端接口性能不只是写接口的人决定了还取决于调用方拿到数据后要做什么。当你返回一个包含50个字段的对象而前端只用到其中5个时那45个字段的序列化、传输和解析就是纯浪费。接口性能优化的最高境界是少传数据能返回摘要的绝不返回详情。很多接口给人感觉慢不是因为处理逻辑复杂而是因为JSON序列化大对象加上网络传输延迟占据了80%的时间。压缩、精简字段、缩小包体积这些手段可以立竿见影。使用Jackson或Gson时默认会序列化getter方法暴露的所有属性包括一些不必要的大字段如base64图片、日志文本等。建议在DTO上使用JsonIgnore或JsonProperty指定字段或者干脆用聚合根模式将接口输出建模为最小结构。对于列表接口用分页代替全量返回对于详情接口提供字段选择参数让调用方按需获取。数据体积每下降一半接口性能就提升一倍这不是夸张的说法。序列化本身也有性能差异。Protobuf、Msgpack等二进制协议比JSON快一个数量级但可读性差、调试困难适合内部服务间调用。如果坚持JSON也要注意序列化库的选择Jackson的性能优于Gson而Gson的灵活性和容错性更好。不要忽略同一个库的配置开启后几乎不费力就能减少10%-20%的序列化时间。还有一个常被忽视的点是HTTP压缩。对文本型JSON开启Gzip通常能压缩到原始体积的20%左右。但要注意CPU开销也会增加需要对压缩级别和阈值做权衡。优化返回数据的本质是消除一切不必要的信息熵让每一次传输都物超所值。五处排查路径讲完了它们之间并非孤立。数据库索引问题往往可以用缓存掩盖外部调用延迟可以用线程池缓解返回数据膨胀可以靠网关压缩。一个成熟的后端工程师看到接口变慢时不会盲目加机器或加缓存而是按顺序排查先看数据库SQL再看缓存命中然后看外部依赖和线程池最后审视返回体积。性能优化不是一锤子买卖而是一套持续运作的反馈机制。压测、监控、日志分析、代码审查每一项都需要长期积累。当你把这五个地方都调优之后或许会发现新的瓶颈出现在网络带宽、磁盘IO甚至操作系统层面。那时你已经具备了系统化排查问题的思路剩下的只是沿这个思路继续深挖下去。