接口慢到被骂？教你5招把响应速度砍掉一半
接口慢，不是运维的锅，是你的代码在拖后腿。
线上接口超过500ms，用户就开始骂。超过2秒，转化率直接掉一截。别急着加服务器——先把这5招用上，多数场景能把响应时间砍掉一半。
第1招：数据库——查慢日志，别猜
接口慢，80%的锅在数据库。
先开慢查询日志，找出执行超过200ms的SQL。常见凶手：
| 问题 | 表现 | 一句话解法 |
|---|---|---|
| 全表扫描 | 表大了查询直接卡死 | 加索引，覆盖WHERE条件 |
| 索引失效 | 明明建了索引还是慢 | 检查LIKE '%xx'、函数包裹字段等写法 |
| N+1查询 | 列表接口查了100次数据库 | 用JOIN或批量IN查询一次拉回 |
| 回表太多 | 索引只覆盖部分字段 | 建联合索引，让索引直接返回结果 |
记住：不看慢日志就优化数据库，等于闭着眼开车。
第2招：加缓存——但别瞎加
缓存是降响应时间最猛的一招。用户信息、配置数据、热点列表，这些读多写少的数据，不该每次都查库。
但有三个坑：
- 缓存穿透——查不存在的数据，每次都打到数据库。解法：空值也缓存，设短TTL（如30秒）。
- 缓存击穿——热点key过期瞬间，大量请求同时打到DB。解法：加互斥锁，或用永不过期+异步更新。
- 缓存雪崩——大批key同时过期，DB瞬间被打垮。解法：过期时间加随机偏移，别让它们"同时死"。
Redis + 本地缓存（Caffeine/Guava）双层架构，是当前最稳的方案。
第3招：异步——能不等就不等
用户点了"提交订单"，他不需要等你发短信、扣积分、写日志。这些事全扔消息队列，接口立刻返回。
同步：下单 → 写库 → 发短信 → 扣积分 → 写日志 → 返回（800ms）
异步：下单 → 写库 → 返回（200ms）
↓
消息队列 → 消费发短信/扣积分/写日志
RocketMQ、Kafka、RabbitMQ选一个就行。关键原则：接口只做必须同步的事，其余全异步化。
第4招：减少返回数据量——别把整个库塞给前端
很多接口慢，不是查得慢，是传得慢。
- 列表接口返回了500条数据，前端只展示20条 → 加分页，限制单次返回条数。
- 详情接口把用户所有字段都返回了，前端只用了3个 → 用字段裁剪（DTO/VO），只返回需要的。
- 嵌套查询一层套一层，N+1把数据库打爆 → 用GraphQL或一次JOIN拉平。
网络传输也是时间。10KB和100KB的响应，在弱网下差的是秒级体验。
第5招：链路追踪——找到真正的瓶颈
以上四招都是"经验优化"，但如果你不知道慢在哪，就是在瞎蒙。
装一个链路追踪工具（SkyWalking、Jaeger、Zipkin），一次请求经过了哪些服务、每个环节花了多少毫秒，一目了然。
真实案例：某团队接口平均响应1.2秒，以为是数据库慢。追踪后发现——数据库只花了80ms，真正的耗时在一个HTTP调第三方接口上，平均等了900ms。加了超时+熔断后，响应直接降到300ms。
不追踪就优化，等于不量体温就开药。
总结：一张表看清优先级
| 招数 | 见效速度 | 投入成本 | 适用场景 |
|---|---|---|---|
| 数据库优化 | ⚡ 立刻见效 | 低 | 几乎所有慢接口 |
| 加缓存 | ⚡ 立刻见效 | 中 | 读多写少的热点数据 |
| 异步化 | 🔧 需改造 | 中高 | 有非核心耗时操作 |
| 减少返回量 | ⚡ 立刻见效 | 低 | 返回数据过大的接口 |
| 链路追踪 | 🔍 先诊断 | 中 | 不知道慢在哪时必做 |
先追踪，再优化。先数据库，再缓存。能异步就别同步，能少传就别多传。
这5招不需要你重构系统，今天就能动手。接口响应时间砍一半，不是梦——是基本功。
