聚合前先查：Elasticsearch中filter与query的本质区别与实战优化
你有没有遇到过这样的场景？
在 Kibana 里写了个聚合查询，想统计最近一周订单按省份的分布。DSL 写完一运行，响应时间竟然要3秒以上，而数据总量其实也就几百万条。更离谱的是，换个时间范围再查一遍，还是这么慢——缓存好像根本没起作用。
如果你也踩过这个坑，那很可能是因为混淆了 Elasticsearch 中两个看似相似、实则天差地别的概念：query和filter。
很多初学者（甚至不少老手）都会误以为“只要能筛出数据就行”，于是不管三七二十一都往must里塞条件。殊不知，正是这种“无心之失”，让本该毫秒级响应的报表查询变得迟钝不堪。
今天我们就来彻底讲清楚：什么时候该用query，什么时候必须用filter？为什么说“聚合前先过滤”是 ES 性能调优的第一法则？
从一个真实案例说起：3倍性能差距是怎么来的？
假设我们有一个电商订单索引orders，每天新增约 50 万条记录。现在需要实现这样一个需求：
统计过去7天内，“已发货”状态的订单数量，并按商品类目分组。
❌ 错误写法：把筛选当搜索
{ "size": 0, "query": { "bool": { "must": [ { "match": { "status": "shipped" } }, { "range": { "order_date": { "gte": "now-7d/d", "lt": "now/d" } } } ] } }, "aggs": { "category_count": { "terms": { "field": "category.keyword" } } } }看起来没问题对吧？功能完全正确。但问题出在哪？
match查询会触发相关性评分（_score）计算；- 即使你并不关心哪个文档更“匹配”，ES 还是会为每一条命中的文档打分；
- 更致命的是，这类基于文本字段的查询无法被有效缓存；
- 每次请求都要重新执行全文扫描 + 评分 → CPU 飙升、响应变慢。
结果就是：每次查询耗时1.8s ~ 2.5s，节点 load 直线上升。
✅ 正确做法：用filter做纯粹的数据预筛
{ "size": 0, "query": { "bool": { "filter": [ { "term": { "status.keyword": "shipped" } }, { "range": { "order_date": { "gte": "now-7d/d", "lt": "now/d" } } } ] } }, "aggs": { "category_count": { "terms": { "field": "category.keyword" } } } }改动很小，但效果惊人：
- 不再计算
_score→ 节省大量 CPU； - 使用
term精确匹配.keyword字段 → 可缓存； - Lucene 底层使用 BitSet 缓存结果集 → 第二次查询几乎瞬时返回；
- 实测平均响应时间降至600ms 左右，性能提升超过3倍！
这还只是单个查询。想象一下，在高并发报表系统中，成百上千个类似请求压下来，错误的写法足以拖垮整个集群。
核心机制解析：query和filter到底有什么不同？
别再死记硬背“一个评分一个不评分”了。我们要从底层逻辑理解它们的根本差异。
| 对比维度 | query | filter |
|---|---|---|
是否计算_score | 是 | 否 |
| 是否影响排序 | 是 | 否 |
| 是否可缓存 | 部分可缓存（依赖具体类型） | 高度可缓存（BitSet） |
| 典型使用场景 | 用户输入关键词搜索 | 时间范围、状态码、分类等结构化过滤 |
| 底层数据结构 | 倒排索引（Inverted Index） | Doc Values + BitSet |
| 性能开销 | 高（涉及 TF-IDF/BM25 计算） | 极低（布尔判断） |
关键点拆解
1._score是性能杀手吗？
不是。它是全文检索的灵魂。
当你在淘宝搜“红色连衣裙夏季”，你需要的是“最相关”的结果排在前面，而不是随机排列。这时候_score就至关重要。
但在做数据分析时呢？比如“统计北京地区的用户活跃数”，所有符合条件的文档都是“平等”的——要么在北京，要么不在。根本不需要打分。
继续打分 = 白白浪费资源。
2. 缓存机制的天壤之别
这是很多人忽略的关键点。
query的缓存粒度细、命中率低。例如{ "match": { "title": "高性能" } }，哪怕只是多一个空格或换种写法，就可能无法复用缓存。filter的缓存基于BitSet，即每个 segment 返回一个位图（哪些 doc ID 匹配），这个位图可以被后续查询直接复用。
举个例子：
"filter": [ { "term": { "region": "beijing" } } ]第一次执行后，ES 会在内存中保存这个条件的结果位图。之后只要有其他查询也需要“北京地区”的数据，就可以直接读取这份缓存，避免重复扫描。
这就是为什么日志平台中“固定时间段+固定服务名”的组合查询越查越快的原因。
3. 数据结构的选择也很关键
注意上面的例子用了"status.keyword"而不是"status"。
因为：
-text类型会被分词，不适合精确匹配；
-keyword是不分词的完整值存储，天然适合term查询；
- 结合doc_values（列式存储），可在不加载全文的情况下完成聚合和过滤。
所以记住一句话：
凡是用于过滤、排序、聚合的字段，请务必使用
.keyword或启用doc_values。
实战指南：如何设计高效的聚合查询？
🎯 原则一：明确你的查询目的
问自己一个问题：我到底是在“找东西”，还是在“统计数据”？
| 场景 | 推荐方式 |
|---|---|
| 用户搜索商品、文章、日志内容 | 使用query |
| 报表统计、指标分析、维度下钻 | 使用filter |
| 复合型需求（如：搜“苹果手机”并限定价格区间） | query+filter混合使用 |
🎯 原则二：永远优先缩小数据集
聚合操作的成本与参与计算的文档数量呈线性甚至超线性增长。因此：
能早过滤就早过滤，越靠近查询入口越好。
最佳实践是在bool查询的filter子句中完成以下常见约束：
"bool": { "filter": [ // 时间窗口（最重要！） { "range": { "@timestamp": { "gte": "now-1h" } } }, // 状态码、枚举值 { "term": { "status.keyword": "active" } }, // 地域、组织、租户隔离 { "term": { "tenant_id": "org_123" } }, // 多条件组合 { "terms": { "category.keyword": ["electronics", "books"] } }, // 空值判断 { "exists": { "field": "user_id" } } ] }尤其是时间范围，几乎应该成为每一个聚合查询的标配。否则你就等于在全量数据上做运算，性能怎么可能好？
🎯 原则三：善用bool查询的组合能力
Elasticsearch 的bool查询就像乐高积木，可以把多种逻辑拼接在一起。关键是把不同类型的条件放到合适的“槽位”里：
"bool": { "must": [ // 必须满足，且影响相关性得分 { "match": { "content": "elasticsearch 教程" } } ], "should": [ // 提升得分，非必需 { "term": { "author.keyword": "张三" } } ], "filter": [ // 必须满足，但不影响得分 → 用 filter！ { "term": { "status.keyword": "published" } }, { "range": { "publish_date": { "gte": "2023-01-01" } } } ], "must_not": [ // 排除某些文档 { "term": { "deleted": true } } ] }重点提醒：
所有结构性、确定性的筛选条件（如状态、时间、权限等），都应该放在
filter里，而不是must！
常见误区与避坑指南
❌ 误区1：用match去查 keyword 字段
// 错误！ { "match": { "status.keyword": "published" } } // 正确！ { "term": { "status.keyword": "published" } }虽然功能上可能等价，但match会走全文解析流程，破坏缓存机制。
❌ 误区2：在filter中使用text字段做 term 查询
// 危险！text 字段可能因分词导致匹配失败 { "term": { "title": "Quick Brown Fox" } }term查询要求完全匹配倒排索引中的 term，而text字段经过分词后可能是quick,brown,fox三个词项，永远不会匹配到原短语。
解决办法：
- 若需精确匹配，使用.keyword子字段；
- 若需语义匹配，使用match查询放入must或should。
❌ 误区3：忽视缓存监控
你以为加了filter就自动缓存了？不一定。
可以通过以下命令查看缓存命中情况：
GET /_nodes/stats/query_cache?human&pretty关注关键指标：
hit_count: 缓存命中次数miss_count: 缓存未命中次数evictions: 因内存不足被淘汰的条目数
理想状态下，高频使用的filter条件应有较高的 hit ratio（建议 >70%）。如果频繁淘汰，说明indices.queries.cache.size设置过小，需要调整。
高阶技巧：结合 runtime field 实现动态过滤
有时候，原始字段不能满足过滤需求。比如你想按“订单金额是否大于1000”来分类统计。
传统做法是提前建模，但这不够灵活。
可以用runtime field动态定义逻辑字段：
"runtime_mappings": { "is_high_value_order": { "type": "boolean", "script": "emit(doc['amount'].value > 1000)" } }然后在filter中使用：
"filter": [ { "term": { "is_high_value_order": true } } ]这种方式无需修改 mapping，适合快速验证业务逻辑。当然，性能略低于原生字段，慎用于高频核心路径。
写在最后：打好基础，才能走得更远
Elasticsearch 功能强大，但也极其“诚实”。你怎么写查询，它就怎么执行，不会替你优化懒惰的设计。
掌握query与filter的本质区别，不只是为了写出更快的 DSL，更是培养一种工程思维：
区分“语义意图”与“技术实现”，让系统各司其职。
未来无论是构建实时推荐引擎、用户行为分析平台，还是接入向量搜索、LLM 日志追踪，你会发现这些底层认知始终是你应对复杂挑战的底气。
对于正在学习 ES 的同学来说，不妨从现在开始，每次写查询前都问一句：
“我是想找到最相关的文档，还是仅仅想圈定一批数据？”
答案明确了，query和filter自然就知道该怎么用了。
如果你在实际项目中遇到类似的性能问题，欢迎在评论区留言交流，我们一起排查优化思路。
