Easysearch 布尔查询子句重排序（一）｜你的 BoolQuery 写法，真的影响性能吗？

Easysearch 布尔查询 BoolQuery 排序

2026-08-26

查看 Markdown

从 Easysearch 到 Lucene，查询构建层的 11 条优化规则

INFINI Easysearch 是一款专注于企业级场景的分布式近实时搜索与分析引擎。它以 Apache Lucene 为内核进行了增强，在保持与行业主流搜索协议及开发生态完全兼容的同时，重点强化了安全性、稳定性、压缩率及信创兼容性。

一、开篇：一个常见的误解 #

“must 里面，是不是应该把匹配文档少的条件写在前面？这样能提前过滤掉大量文档，性能更好？”

这个直觉来得很自然，但它是错的。

┌─────────────────────────────────────┐
│  用户的直觉：                         │
│  must: [高频词, 低频词] → 慢          │
│  must: [低频词, 高频词] → 快          │
│                                     │
│  实际情况：                          │
│  两种写法性能完全相同！                │
│  Lucene 执行时自动按 cost 排序        │
└─────────────────────────────────────┘

Easysearch 执行时会按 cost 自动重排子句顺序，与你写查询时的顺序无关。不过"子句顺序不重要"并非处处成立，它有一条跟版本挂钩的边界——must/filter 里混入 prefix/wildcard 这类多词查询时，老版本引擎会重新对顺序敏感（详见 第二篇 §八的边界说明）。而且"子句顺序不重要"也不代表"怎么写都一样"——理解引擎自动优化的边界在哪里，才能设计出更合理的查询结构。

本文是系列第一篇，聚焦构建层：从你发出 JSON 到查询进入执行引擎，中间经历了哪些变换？哪些优化在这个阶段完成？哪些要留到执行层？后续三篇将分别深入合取查询的 cost 排序、析取查询的 WAND 剪枝，以及 Block-Max 块级剪枝与实战验证。

二、全景：一次布尔查询的完整旅程 #

先建立一张全局地图，再深入每一层。

举个例子：一条布尔查询就像一个包裹进入工厂流水线，经过三道工序：

• 第一道（Easysearch 层）：质检员检查包裹格式是否合规，缺不缺东西，但不重新排列里面的物品顺序
• 第二道（Lucene rewrite）：工艺师合并重复部件、去掉矛盾组合、把"可选"升级为"必选"——改变的是包裹的内容结构，不是物品顺序
• 第三道（Scorer 层）：调度员拿到最终包裹，按每个部件的"处理成本"自动安排加工顺序——这才是代价排序发生的地方

用技术语言描述，这三道工序对应的是（注意①和②③分属不同阶段）：

用户 JSON
   │
   ▼
┌──────────────────────────────────────────┐
│  Easysearch 层（构建层）                   │
│  ① doRewrite() — 递归重写 + 早期终止       │
│  ② applyMinimumShouldMatch              │
│  ③ fixNegativeQueryIfNeeded             │
│  （①在 rewrite 阶段，②③在 doToQuery()内）│
│  职责：结构合法化，不改子句顺序              │
└────────────────┬─────────────────────────┘
                 │ toQuery() → BooleanQuery
                 ▼
┌────────────────────────────────────────────┐
│  Lucene rewrite 层（逻辑重写层）             │
│  ④ BooleanQuery.rewrite()                 │
│  （IndexSearcher 中 rewrite→createWeight） │
│  职责：11条逻辑等价改写，不改结果只改形态       │
└────────────────┬───────────────────────────┘
                 │ createWeight()
                 ▼
┌──────────────────────────────────────────┐
│  Scorer 构造层（执行层）                   │
│  ⑤ ConjunctionDISI：按 cost() 排序 ✅    │
│  ⑥ WANDScorer：按 maxScore 动态重排 ✅    │
│  职责：代价感知，真正的性能优化在这里         │
└────────────────┬─────────────────────────┘
                 │
                 ▼
           执行查询，返回结果

一个关键认知：代价排序发生在第⑤步（Scorer 层）。前两道工序只做逻辑等价改写——合并重复、升级类型、展平嵌套，但不改变查询结果。

本文讲前两层（①~④），后三篇讲第⑤⑥步。

三、Easysearch 层：结构合法化，不碰顺序 #

你发出的 JSON，首先被 Easysearch 的 BoolQueryBuilder 解析成内部的查询对象。这一层做的事情很克制：保证查询结构合法，但不改变子句顺序。

3.1 子句是如何被添加的 #

BoolQueryBuilder.doToQuery() 按照固定顺序把子句添加到 Lucene 的 BooleanQuery.Builder 中：

must → mustNot → should → filter

不同类型之间的添加顺序是固定的（无论你的 JSON 里先写 should 还是先写 must），但同一类型内的子句顺序与 JSON 书写顺序一致——这通常不影响性能，因为代价排序发生在更下游的 Scorer 层；唯一的例外见 第二篇 §八：老版本上混入多词查询时，书写顺序仍会起作用。

3.2 三种特殊处理 #

Easysearch 层会做三类结构合法化处理：

doRewrite() 的早期终止：

• 如果整个 BoolQuery 为空（没有任何子句），退化为 MatchAllQueryBuilder（等价于 Lucene 的 MatchAllDocsQuery）
• 如果任何 must 或 filter 子句重写后变为 MatchNoneQueryBuilder，整个 BoolQuery 直接返回该 MatchNoneQueryBuilder——不需要继续执行
• 如果没有 must/filter 子句，但所有 should 子句都重写为 MatchNoneQueryBuilder，整个 BoolQuery 也退化为 MatchNoneQueryBuilder——没有必须匹配的子句，所有可选子句又都匹配零文档，结果必然为空

fixNegativeQueryIfNeeded()： 当查询只有 must_not 子句、没有任何正向匹配条件时，Lucene 的 BooleanQuery 不知道"从哪些文档里排除"。Easysearch 自动插入一个 MatchAllDocsQuery 作为基础集合。该修复受 adjust_pure_negative 开关控制（默认为 true，可设为 false 关闭）：

输入：must_not: [term:spam]
处理：加入 MatchAllDocsQuery (作为 FILTER)
输出：filter: [MatchAll] + must_not: [term:spam]
      = "所有文档 除了 spam"

applyMinimumShouldMatch()： 把用户设置的 minimum_should_match 规格字符串（支持整数 "2"、百分比 "75%"、条件式 "3<75%" 等）解析为 int，写入 Lucene 的 BooleanQuery.setMinimumNumberShouldMatch()。

总结：**Easysearch 层不改变子句顺序，只做合法化修补。**真正的优化交给下游。

四、Lucene rewrite 层：11 条逻辑等价改写规则 #

查询经过 toQuery() 变成 Lucene 的 BooleanQuery 对象后，会调用 BooleanQuery.rewrite()。这是本文的核心章节。

这一层不做代价排序，而是通过 11 条规则改写查询的形态——去重、提升、展平——但保证改写前后查询结果完全一致，为后续执行层的高效优化铺路。

📌 本文按理解难度递进排列规则编号。源码中 BooleanQuery.rewrite() 实际包含 12 个步骤，本文将其中 SHOULD 去重和 MUST 去重合并为规则 8，并按逻辑将 MatchAll→ConstantScore 编为规则 11，因此源码实际执行顺序按本文编号为：1→2→3→4→5→6→7→8→11→9→10（ConstantScore 转换在展平和 minShouldMatch 对齐之前执行）。

规则 1-3：消除不可能、去重、矛盾检测 #

这三条是防御性规则，含义很容易理解，快速过一遍：

规则 2 示例：
BooleanQuery { MUST: [TermQuery(status:published)] }
       ↓  rewrite
TermQuery(status:published)

BooleanQuery { FILTER: [TermQuery(status:published)] }
       ↓  rewrite
BoostQuery(ConstantScoreQuery(TermQuery(status:published)), 0)

规则 3 示例：
must: [MatchNoDocsQuery], should: [TermQuery(A)]
       ↓  rewrite（MUST 中含 MatchNoDocs → 整体短路）
MatchNoDocsQuery

规则 4-6：去重、矛盾检测、冗余移除 #

继续快速过：

规则 4 示例：
filter: [term:active, term:active, range:age>18] → filter: [term:active, range:age>18]

规则 6 示例：
must: [term:active], filter: [term:active, range:age>18] → must: [term:active], filter: [range:age>18]

规则 7：SHOULD + FILTER → MUST 提升 ⭐ #

触发条件：同一个子查询同时出现在 SHOULD 和 FILTER 子句中。

行为：将该子查询的 SHOULD 子句改为 MUST（原 FILTER 子句直接丢弃，因为 MUST 已隐含了 FILTER 的过滤语义）。源码里会同时下调 minimumNumberShouldMatch（每提升一个子句 minShouldMatch--，循环结束后统一 Math.max(0, minShouldMatch) 确保不低于 0）：

• 若提升后 minShouldMatch == 0，mix 路径走 req+opt（ReqOptSumScorer）
• 若提升后 minShouldMatch > 0，仍走 conjunction-disjunction mix（ConjunctionScorer(req,opt)）

也就是说，规则 7 一定会改变查询形态，但是否切到 ReqOptSumScorer 取决于 minShouldMatch 是否归零。

优化前：
┌───────────────────────┐
│ SHOULD: [term:A]      │
│ FILTER: [term:A]      │
│ SHOULD: [term:B]      │
└───────────────────────┘
         ↓  rewrite
优化后：
┌───────────────────────┐
│ MUST:   [term:A]      │  ← 提升为 MUST！
│ SHOULD: [term:B]      │
└───────────────────────┘

💡 类比：一个人同时是"候选人"（SHOULD）又是"已入职"（FILTER）。既然已经入职，直接列入正式编制（MUST）。

⚠️ minShouldMatch 联动：每将一个 SHOULD 提升为 MUST，minimumNumberShouldMatch 相应减 1（循环结束后 Math.max(0, minShouldMatch) 兜底），确保语义等价。例如原有 minimum_should_match: 2 且两个 SHOULD 中有一个被提升，重写后 minShouldMatch 变为 1。

规则 8：SHOULD / MUST 去重（boost 求和） #

触发条件：SHOULD 或 MUST 中出现了相同的子句（解包 BoostQuery 后底层查询相同）。注意：SHOULD 去重仅在 minimumNumberShouldMatch ≤ 1 时触发；若 minShouldMatch > 1，Lucene 不会合并重复的 SHOULD 子句（多个重复出现在高 minShouldMatch 场景下语义不可简单合并）。MUST 去重则没有此限制，无论 minShouldMatch 为何值都会合并重复的 MUST 子句。

行为：合并重复子句，将它们的 boost 相加。FILTER 和 MUST_NOT 的去重由规则 4 处理（直接删除），而 SHOULD 和 MUST 的重复是有意义的——不同的 boost 意味着不同的评分权重，所以求和保留。不合并的话，同一个 term 会创建两套独立的迭代器，都遍历相同的文档列表，浪费翻倍。

should: [term:hello^1.5, term:hello^2.0, term:world]
       ↓  rewrite
should: [term:hello^3.5, term:world]
（两个 hello 的权重合并：1.5 + 2.0 = 3.5）

💡 类比：一个学生选了同一门课两次，一次记 1.5 学分，一次记 2 学分。不需要上两次课，合并为 3.5 学分即可。

规则 9：SHOULD 嵌套展平 ⭐ #

触发条件：一个 bool 查询的 SHOULD 子句里，嵌套了另一个纯 SHOULD 的 bool 查询（即内层没有 MUST、FILTER、MUST_NOT，只有 SHOULD，且 minimum_should_match ≤ 1）。

行为：把内层 SHOULD 子句全部"提升"到外层，展平为同一级别的 SHOULD 子句。展平后 WAND 能看到每个子句的独立 maxScore，估算更紧，剪枝更激进；如果不展平，WAND 只能看到内层查询的总体上界（黑盒），剪枝不够狠。

优化前：
       BoolQuery (外层)
      /                \
   SHOULD            SHOULD
  (term:A)        (内层 BoolQuery)
                     /      \
                 SHOULD    SHOULD
                (term:B)  (term:C)

         ↓  rewrite

优化后：
       BoolQuery
      /    |    \
  SHOULD SHOULD SHOULD
 (term:A)(term:B)(term:C)

实践建议：如果你在 should 里嵌套了多层 bool，且内层全是 SHOULD 子句，EasySearch 会自动展平。但如果内层有 minimum_should_match >= 2，则不会展平（语义不等价），这类情况应尽量手动展平或重构查询结构。

💡 为什么展平能更激进地剪枝？假设内层 bool 有两个子句，maxScore 分别是 8 和 3。展平前，WAND 只看到"这个内层查询最多得 8+3=11 分"，不管当前文档匹配了哪些子句，上界永远是 11；展平后，WAND 逐子句检查——某个文档如果不匹配 maxScore=8 的子句，只剩 maxScore=3 的子句可能匹配，上界从 11 降到 3。如果录取线是 5，3 < 5，这个文档不可能入选——直接跳过，不用再算分了。

规则 10：SHOULD 数量与 minimumShouldMatch 的对齐 #

触发条件：SHOULD 子句数量与 minimum_should_match 的大小关系。

行为：分两种情况：

• SHOULD 数量 < minimumShouldMatch：不可能满足 → 直接返回 MatchNoDocsQuery，省去无用计算
• SHOULD 数量 == minimumShouldMatch：所有 SHOULD 提升为 MUST，从 WANDScorer（调度开销大）转入 ConjunctionDISI（cost 排序，更高效）

should: [A, B]，minimum_should_match: 3
       ↓  rewrite（2 < 3，不可能满足）
MatchNoDocsQuery

should: [A, B, C]，minimum_should_match: 3
       ↓  rewrite（3 == 3，等价于全部 MUST）
must: [A, B, C]

💡 类比：开会时，如果"3 个可选发言人必须全部到场"——那"可选"就没意义了，等价于"3 个必须到场"。如果要求"3 人到场但只有 2 人可选"——不可能，直接取消会议。

一个容易忽略的场景：在动态拼接查询时（例如从用户的多个筛选条件生成 should，然后设置 minimum_should_match 等于条件数量），这条规则会自动把它转化为更高效的 MUST 查询，无需手动改写。

规则 11：MatchAll + FILTER → ConstantScoreQuery #

触发条件：BooleanQuery 恰好只有一个 MUST 子句且为 MatchAllDocsQuery，且至少有一个 FILTER 子句。

行为：将所有 FILTER + MUST_NOT 组成内部 BooleanQuery，整体包裹为 ConstantScoreQuery（绕过评分，返回固定分数），作为外层 MUST 加入；SHOULD 子句加回外层（不丢弃）；原始 MatchAllDocsQuery 被消耗。MatchAllDocsQuery 在 BooleanQuery 框架里有额外调度开销，ConstantScoreQuery 执行路径更直接。

⚠️ 注意：纯 filter 查询没有 MUST 子句，不满足 musts.size() == 1 的前提，不触发本规则。FILTER 子句直接进入合取路径，由 ConjunctionDISI 按 cost 排序处理。

在 11 条规则中，标 ⭐ 的规则 7（SHOULD+FILTER→MUST）和规则 9（SHOULD 嵌套展平）对执行性能影响最大——前者决定子句能否进入 ConjunctionDISI 的 cost 排序路径，后者决定 WANDScorer 能否做全局剪枝。

五、实战：一条 rewrite 规则如何改变执行路径 #

前面列了 11 条规则，这一节用具体例子展示：构建层的一条 rewrite 规则，如何直接影响执行层的路径选择。

假设你有一个查询：

{
  "bool": {
    "should": [
      { "term": { "status": "published" } },
      { "term": { "category": "ai" } }
    ],
    "filter": [{ "term": { "status": "published" } }]
  }
}

status:published 同时出现在 should 和 filter——规则 7 会把它提升为 MUST，并下调 minShouldMatch。下图假设提升后 minShouldMatch=0，执行路径因此发生根本变化：

┌─────────────────────────────────────────────────────────────────┐
│  没有 rewrite 优化（假设）                                        │
│  minShouldMatch=1，走 conjunction-disjunction mix 路径           │
│                                                                 │
│  ┌────────────────────────────┐                                 │
│  │ ConjunctionScorer          │                                 │
│  │ ├─ FilterScorer            │  published 出现两次：            │
│  │ │  published (score=0)     │  • FILTER 里遍历一遍（只过滤）     │
│  │ └─ DisjunctionSumScorer    │  • SHOULD 里再遍历一遍（评分）     │
│  │    ├─ published            │  = 同一个 term 被两个迭代器        │
│  │    └─ ai                   │    各跑一遍，浪费！               │
│  └────────────────────────────┘                                 │
└─────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────┐
│  rewrite 优化后（实际）                                           │
│  minShouldMatch=0，走 req+opt 路径                               │
│                                                                 │
│  ┌────────────────────────────┐                                 │
│  │ ReqOptSumScorer            │  published 只出现一次：           │
│  │ ├─ req: published (有评分)  │  • 作为 MUST，一次迭代同时        │
│  │ └─ opt: ai (可选加分)       │    完成过滤和评分                 │
│  └────────────────────────────┘                                 │
└─────────────────────────────────────────────────────────────────┘

优化前，status:published 被两个迭代器各遍历一遍；优化后，一次迭代同时完成过滤和评分——一条 rewrite 规则，改变了执行路径的选择。它不做代价排序，但决定了哪些子句有资格进入更高效的路径。

六、动手验证：用 Profile API 观察 rewrite 效果 #

理论再多，不如自己跑一遍。Easysearch 的 Profile API 可以直接暴露 rewrite 后的查询形态，不需要读源码，几秒钟就能验证。

6.1 验证规则 7：SHOULD + FILTER → MUST 提升 #

准备好一个含有 status 和 category 字段的索引，执行：

GET /products/_search
{
  "profile": true,
  "query": {
    "bool": {
      "should": [
        { "term": { "status": "published" }},
        { "term": { "category": "ai" }}
      ],
      "filter": [
        { "term": { "status": "published" }}
      ]
    }
  }
}

找到响应中 profile.shards[0].searches[0].query[0].description 字段（具体格式可能因版本略有不同）：

• 你写的：SHOULD + FILTER 并存（两个地方都有 status:published）
• 实际执行：+status:published category:ai

注意 + 前缀——在 Lucene 的查询 description 语法中，+ 表示 MUST，没有符号表示 SHOULD。status:published 前面有 +，说明 rewrite 已经把它提升为 MUST，查询形态已经发生了变化。

6.2 验证规则 10：SHOULD 数量 == minimumShouldMatch → 全部提升为 MUST #

GET /products/_search
{
  "profile": true,
  "query": {
    "bool": {
      "should": [
        { "term": { "status": "published" }},
        { "term": { "category": "ai" }}
      ],
      "minimum_should_match": 2
    }
  }
}

profile 的 description 应该显示 +status:published +category:ai——两个 term 都带 + 前缀，说明全部提升为 MUST，这个查询实际上会走第二篇要讲的 ConjunctionDISI 路径，而非 WANDScorer。

6.3 理解 Profile 响应的结构 #

一个完整的 Profile 响应包含大量信息，但读懂核心字段只需关注三个位置：

{
  "profile": {
    "shards": [{
      "searches": [{
        "query": [{
          "type": "BooleanQuery",
          "description": "+status:published +category:ai",
          "breakdown": {
            "next_doc": 12750,      "next_doc_count": 1,
            "advance":  0,          "advance_count":  0,
            "create_weight": 375375, "create_weight_count": 1,
            "build_scorer":  248958, "build_scorer_count":  2
          },
          "children": [
            { "type": "TermQuery", "description": "status:published", ... },
            { "type": "TermQuery", "description": "category:ai", ... }
          ]
        }],
        "rewrite_time": 146958
      }]
    }]
  }
}

快速解读三个关键位置：

💡 小技巧：breakdown 里每个指标都有两个 key——xxx 是耗时（纳秒），xxx_count 是调用次数。想看"做了多少次"看 _count，想看"花了多少时间"看不带 _count 的。

七、小结与预告 #

我们走完了布尔查询在执行前的两个构建层：

Easysearch 层做的是合法化处理——保持子句顺序，修补极端情况（纯否定、空查询、MatchNone 短路），设置 minShouldMatch。它不会改变你查询的"形状"。

Lucene rewrite 层通过 11 条逻辑等价改写规则改变查询的"形态"：

• 规则 1-6 是防御性规则，消除空查询、冗余和矛盾
• 规则 7 和规则 10 是提升性规则，把更多子句导入 ConjunctionDISI 的合取路径，为 cost 排序创造更大的发挥空间
• 规则 9 是为析取优化准备的，展平 SHOULD 嵌套让 WANDScorer 能做全局剪枝
• 规则 8 是评分优化（合并重复 boost），规则 11 绕过不必要的评分计算

这两层都不做代价排序，但它们决定了哪些子句有资格进入更高效的执行路径。

下一篇预告

当 MUST 子句进入 Scorer 构造层，Lucene 会创建 ConjunctionDISI，对所有迭代器按 cost() 升序排序——最稀疏的放在第一位，承担"领头"角色，最大限度地用跳转（advance()）跳过不满足条件的文档。

匹配文档最少的迭代器，为什么反而被选来驱动整个遍历？——它产生的候选集最小，所有迭代器的验证次数因此被压到最低。这个看似"以弱领强"的设计，正是合取查询性能优化的核心。我们在第二篇，通过源码、图解和 Profile API 实测，把这个机制讲透。