1. ElasticSearch复合查询概述
在ElasticSearch的实际应用中，复合查询(Compound Query)是最常用的查询类型之一。它允许我们将多个查询条件以逻辑方式组合起来，构建更复杂的查询逻辑。就像搭积木一样，通过不同查询条件的排列组合，我们可以实现各种业务场景下的精准检索需求。
复合查询之所以重要，是因为在实际业务中，单纯的词条匹配或全文搜索往往无法满足需求。比如电商平台需要同时考虑商品分类、价格区间、用户评价等多个维度；内容平台需要结合文章标签、发布时间、作者权重等条件。这些场景都需要通过复合查询来实现。
ElasticSearch提供了四种核心的复合查询类型：
- bool查询：通过must/should/must_not/filter组合多个子查询
- boosting查询：调整特定查询条件的相关性权重
- constant_score查询：为子查询赋予固定分数
- dis_max查询：从多个查询中选取最高分
接下来我将重点解析bool查询的实战应用，这是日常开发中使用频率最高的复合查询类型。
2. bool查询深度解析
2.1 bool查询的基本结构
bool查询就像是一个逻辑容器，可以包含四种类型的子句：
json复制{
"query": {
"bool": {
"must": [],
"should": [],
"must_not": [],
"filter": []
}
}
}
每个子句都可以包含一个或多个查询条件，它们的行为差异如下：
| 子句类型 | 作用 | 是否影响相关性评分 | 典型应用场景 |
|---|---|---|---|
| must | 必须匹配 | 是 | 核心条件过滤 |
| should | 应该匹配 | 是 | 次要条件或提升相关性 |
| must_not | 必须不匹配 | 否 | 排除特定结果 |
| filter | 必须匹配 | 否 | 不关心评分的过滤条件 |
2.2 实际应用案例
假设我们正在开发一个电商商品搜索功能，需要实现以下需求：
- 必须属于"电子产品"分类
- 价格在1000-5000元之间
- 优先展示有库存的商品
- 排除差评率超过30%的商品
- 名称中包含"手机"的商品应该获得更高评分
对应的bool查询可以这样构建：
json复制{
"query": {
"bool": {
"must": [
{ "term": { "category": "电子产品" }},
{ "range": { "price": { "gte": 1000, "lte": 5000 }}}
],
"should": [
{ "term": { "name": "手机" }},
{ "term": { "in_stock": true }}
],
"must_not": [
{ "range": { "bad_review_rate": { "gt": 0.3 }}}
],
"filter": [
{ "exists": { "field": "specifications" }}
]
}
}
}
2.3 评分机制详解
bool查询的评分机制是理解其行为的关键。当多个子查询组合时，最终的_score计算遵循以下规则：
- must和should子句的分数会累加
- 每个匹配的should子句都会增加分数
- 可以使用minimum_should_match参数控制should的最小匹配数
- filter和must_not不影响评分，只做过滤
一个常见的误区是认为should是"或"的关系。实际上，should的默认行为是"加分项"而非"必选项"。如果需要实现逻辑"或"，需要设置minimum_should_match=1。
3. 其他复合查询类型
3.1 constant_score查询
当我们需要给某些查询固定分数时，constant_score就派上用场了。这在某些业务场景下非常有用，比如：
json复制{
"query": {
"constant_score": {
"filter": {
"term": { "is_featured": true }
},
"boost": 1.2
}
}
}
这个查询会给所有is_featured=true的文档固定1.2的分数，而不再计算term查询本身的评分。
提示：constant_score虽然简单，但在实际业务中非常实用。比如可以给VIP用户发布的内容固定加分，或者给特定标签的内容设置固定权重。
3.2 dis_max查询
dis_max（Disjunction Max）查询适用于我们需要从多个查询中取最高分的场景。比如同时搜索标题和内容时：
json复制{
"query": {
"dis_max": {
"queries": [
{ "match": { "title": "智能手机" }},
{ "match": { "description": "智能手机" }}
],
"tie_breaker": 0.3
}
}
}
这里会取title和description匹配中的最高分，tie_breaker参数用于控制其他查询的分数参与度（0-1之间）。
3.3 boosting查询
boosting查询允许我们降低某些条件的权重而非完全排除：
json复制{
"query": {
"boosting": {
"positive": {
"match": { "content": "人工智能" }
},
"negative": {
"match": { "content": "广告" }
},
"negative_boost": 0.2
}
}
}
这个查询会查找包含"人工智能"的内容，但对包含"广告"的结果会将其分数乘以0.2。
4. 复合查询性能优化
4.1 查询结构优化
在实际使用中，查询结构的合理安排能显著提升性能：
- 将高选择性的条件放在前面
- 尽量使用filter代替must用于不关心评分的条件
- 避免过度嵌套bool查询
- 合理使用query context和filter context
4.2 缓存机制利用
ElasticSearch会自动缓存filter查询的结果。因此，对于频繁使用且不关心评分的条件，应该放在filter中：
json复制{
"query": {
"bool": {
"must": [
{ "match": { "title": "笔记本" }}
],
"filter": [
{ "term": { "category": "电脑" }},
{ "range": { "price": { "lte": 8000 }}}
]
}
}
}
4.3 分片查询控制
对于大型集群，可以通过preference参数控制查询执行的分片：
json复制{
"query": { ... },
"preference": "_local"
}
常用preference选项：
- _local：优先本地分片
- _primary：只查询主分片
- 自定义字符串：相同字符串会路由到相同分片
5. 常见问题排查
5.1 查询结果不符合预期
当bool查询结果与预期不符时，可以按以下步骤排查：
-
使用explain API查看评分详情：
bash复制GET /products/_explain/123 { "query": { ... } } -
检查各子句的实际匹配情况
-
确认should子句的minimum_should_match设置
-
验证analyzer对查询词的处理
5.2 性能问题诊断
对于慢查询，可以通过以下方式诊断：
-
启用慢查询日志
json复制PUT /_settings { "index.search.slowlog.threshold.query.warn": "10s", "index.search.slowlog.threshold.query.info": "5s" } -
使用Profile API分析查询执行细节
json复制{ "profile": true, "query": { ... } } -
检查查询涉及的文档数量
-
评估查询复杂度是否合理
5.3 相关性调优技巧
提升搜索结果的相关性需要反复调试：
- 使用function_score自定义评分
- 合理设置boost值
- 结合业务数据调整analyzer
- 考虑用户行为数据（点击率、购买率等）作为评分因素
6. 实战经验分享
在实际项目中使用复合查询时，我总结了一些宝贵经验：
-
结构化设计：将复杂查询拆分为多个逻辑块，就像写程序一样模块化设计查询结构。这样既便于维护，也方便性能优化。
-
渐进式构建：不要试图一次性写出完美查询。应该先构建基础查询，然后逐步添加条件，每步都验证结果是否符合预期。
-
评分验证：对于关键业务查询，应该抽样检查评分结果是否合理。可以使用explain API查看具体评分细节。
-
性能监控：为重要查询建立性能基线，定期监控执行时间变化。当性能下降超过20%时就应该考虑优化。
-
版本兼容：不同版本的ElasticSearch在查询语法和评分机制上可能有细微差别。升级版本后要重新验证关键查询的行为。
一个典型的查询优化案例：某电商平台发现搜索响应时间从200ms增长到了1.2s。通过Profile API分析发现是一个嵌套很深的bool查询导致的。通过以下优化将时间降到了300ms：
- 将部分must条件改为filter
- 减少嵌套层级
- 为常用filter条件添加了缓存
- 调整了分片查询策略