当前位置：首页 > news >正文

别再让 ES 把你拖垮！5 个实战技巧让搜索性能提升 10 倍

news 2026/3/26 17:18:54

“搜索怎么又慢了？”

这是每一个后端工程师在大促期间最不想听到的来自产品经理的“灵魂拷问”。

Elasticsearch（ES）虽然是搜索界的扛把子，但它也是出了名的“资源吞噬者”。如果不懂底层原理，随意建索引、乱写 DSL，你的 ES 集群很快就会变成一个内存黑洞和CPU 绞肉机。

上一篇我们讲了《搜索原理与 DSL 查询实战》，解决了“怎么查”的问题。今天，我们要解决更致命的问题：怎么查得快？

结合我在生产环境踩过的无数坑，总结出这 5 个立竿见影的实战技巧，照着做，至少能让你的搜索性能提升一个数量级。

技巧一：彻底告别`from + size`，拥抱`search_after`

场景：你在做一个无限滚动的商品列表，用户滑到了第 100 页（from=1000, size=10）。
后果：ES 性能断崖式下跌，甚至直接 OOM。

原理：
传统的from + size是“分散-收集”模式。协调节点需要从每个分片获取from + size条数据，然后在内存中进行全局排序，最后截取出你要的那size条。
比如from=10000，协调节点需要从每个分片拉取 10010 条数据，网络开销巨大，且排序是 CPU 密集型操作。

实战方案：
使用search_after代替分页。它利用上一页的最后一条数据的排序值作为“游标”，告诉 ES：“从这个位置之后开始找”。

代码对比：

❌慢查询（深度分页）：

GET/products/_search{"from":10000,"size":10,"query":{"match_all":{}},"sort":[{"create_time":"desc"},{"_id":"asc"}]}

✅快查询（游标分页）：

GET/products/_search{"size":10,"query":{"match_all":{}},"search_after":["2023-10-27T10:00:00Z","doc_id_12345"],"sort":[{"create_time":"desc"},{"_id":"asc"}]}

注意：search_after的参数必须与sort顺序一致，且必须包含一个唯一值（如_id）防止漏数据。

效果：查询耗时从秒级降低到毫秒级，且不随页码加深而变慢。

技巧二：Query 是杀手，Filter 是救星

场景：查询“标题包含手机”且“状态为在售”的商品。
错误写法：把所有条件都放在must里。

原理：

Query Context（如match,bool must）：需要计算相关性评分（_score），涉及 TF-IDF 算法，消耗 CPU。
Filter Context（如term,bool filter）：只回答“是/否”，不计算分数。结果会被缓存（Bitset），后续同样的过滤直接命中缓存，速度极快。

实战方案：
黄金法则：能用 Filter 的，绝不用 Query！

❌低效写法：

"bool":{"must":[{"match":{"title":"手机"}},{"term":{"status":"on_sale"}}]}

✅高效写法：

"bool":{"must":[{"match":{"title":"手机"}}],"filter":[{"term":{"status":"on_sale"}}]}

先用filter砍掉 90% 的无关数据，再对剩下的 10% 做全文匹配评分，性能提升不是一点点。

技巧三：字段映射（Mapping）瘦身计划

场景：索引越来越大，查询越来越慢，磁盘告急。
原因：ES 默认很“大方”。一个text字段，它会自动生成多个子字段（keyword,text,_source等），还会存储norms（用于评分）和_all。

实战方案：

禁用不需要的特性：如果不需要对某字段做全文搜索评分（如 ID、状态码、标签），直接设为keyword或match_only_text。
关闭_source：对于日志类场景，如果原始 JSON 不需要存储（只需搜索），在 Mapping 中关闭_source，可节省 30%-40% 存储空间。
使用match_only_text（ES 7.10+）：如果你只需要分词搜索，不需要词频统计（评分），用这个类型代替text，性能更好，体积更小。

示例：

"mappings":{"properties":{"log_message":{"type":"match_only_text"},"host_name":{"type":"keyword"}}}

技巧四：索引生命周期管理（ILM）—— 热温冷架构

场景：半年前的订单数据还在占用宝贵的 SSD 资源，导致新数据写入变慢。

实战方案：
实施ILM（Index Lifecycle Management）策略，让数据“流动”起来：

Hot（热）阶段：最近 7 天的数据。使用 SSD 硬盘，副本数设为 1，刷新间隔短（如 1s），保证写入和查询最快。
Warm（温）阶段：7-30 天的数据。使用普通 HDD，副本数降为 0（或只读），合并 Segment，减少资源占用。
Cold（冷）阶段：30 天以上的数据。甚至可以冻结索引（Freeze Index），将其从内存中卸载，查询时再加载。查询虽然慢一点，但几乎不耗资源。
Delete：超过保留期直接删除。

效果：用最低的成本支撑海量数据，不再为“历史数据拖慢实时业务”而头疼。