公司内部的知识库系统最近老被同事吐槽，一搜关键词就得等七八秒，有人甚至开玩笑说不如自己翻文档。类似的情况在日常运维中并不少见，搜索功能响应慢，表面看是功能可用，实则严重影响效率。别急着重启服务或者升级服务器，先一步步把根因摸清楚。
先看是不是查询量突然上来了
某天早上刚上班，搜索请求集中爆发，响应时间立刻拉长，这种情况很常见。可以查一下日志里单位时间内的搜索请求数，对比平时的数据。如果流量突增明显，可能是某个新功能上线触发了批量查询，或者是定时任务在跑全文索引检索。这时候加机器不一定治本，得考虑限流或错峰执行。
检查索引是否合理
有个项目之前把数据库的全文搜索直接暴露给前端，用户搜个“订单”能扫几百万条记录，不出问题才怪。后来加上了 Elasticsearch，但索引设计没优化，字段全塞进去，写入快了，查起来还是慢。合理的做法是根据高频查询条件建倒排索引，冷门字段不要参与主索引。比如商品搜索，名称、类目、标签这些该建的建，库存数量这种数值字段除非要范围查，否则别往里加。
GET /products/_search
{
"query": {
"match": {
"product_name": "笔记本电脑"
}
},
"_source": ["name", "price", "category"]
}网络和中间件延迟也不能忽视
有一次线上问题，查了半天应用和数据库都正常，最后发现是搜索服务和 ES 集群跨了机房，走公网链路，高峰期丢包率高，RTT 从 5ms 涨到 120ms。后来改成同机房部署，延迟立马降下来。如果你的服务架构里搜索请求要经过网关、负载均衡、防火墙多层转发，每一跳都可能积压一点延迟，用 tcpdump 或者链路追踪工具抓一抓，心里就有数了。
缓存用好了能省大劲
不是所有搜索都得实时查数据。像用户常搜的热门词，比如“报销流程”“打卡异常”，完全可以把结果缓存几分钟。Redis 里存个 hash，key 是搜索词，value 是结果集 JSON，下次命中直接返回。当然要注意缓存穿透和雪崩，加个随机过期时间，别让所有缓存同时失效。
SET search:cache:报销流程 "{\"results\":[...]}" EX 300 NX最后看看是不是代码层面拖后腿
有次代码审查发现，一个搜索接口在拿到 ES 返回结果后，又挨个去查用户权限表，每条记录发一次 SQL，上千条结果就发上千次请求。这种 N+1 查询问题在实际项目里太常见了。改法也不难，先把用户权限批量捞出来做成映射表，再一次性过滤结果，响应时间从 6 秒降到 400 毫秒。
搜索慢不一定是基础设施不行，更多时候是细节没抠到位。与其盲目扩容，不如从请求入口一路往下捋，哪个环节卡了就修哪个。小改动往往比大投入更见效。