Easysearch 布尔查询优化（上）｜写法不影响顺序，结构才影响性能

（这个“上下”两篇的系列文章，是另外四篇的精简版）

从一个常见误解说起：must 里把匹配少的条件写前面，真的更快吗？

一、一个常见的误解

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

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

用户的直觉： must: [高频词, 低频词] → 慢 must: [低频词, 高频词] → 快 实际情况： 两种写法性能完全相同！ Easysearch 执行时会自动按代价重排子句

Easysearch 在执行时会按代价自动重排子句顺序，与你写查询时的顺序无关。但"子句顺序不重要"不代表"怎么写都一样"——理解引擎自动优化的边界在哪里，才能设计出更合理的查询结构。

本系列分上下两篇。本篇讲前半程：从你发出 JSON 到查询开始执行，引擎做了哪些自动优化，以及合取（must / filter）查询是怎么提速的。下篇讲析取（should）查询的剪枝与实战验证。

二、一次布尔查询的完整旅程

先把全局地图建立起来。一条布尔查询就像一个包裹进入工厂流水线，经过三道工序：

你的 JSON bool 查询 │ ▼ ┌──────────────────────────────────────┐ │ 第一道 Easysearch 层 │ │ 质检：结构合法化，不碰子句顺序 │ ← §三 └──────────────────┬───────────────────┘ ▼ ┌──────────────────────────────────────┐ │ 第二道 Lucene 改写层 │ │ 工艺：去重 / 提升 / 拍平，等价改写 │ ← §四 └──────────────────┬───────────────────┘ ▼ ┌──────────────────────────────────────┐ │ 第三道 执行层（代价排序在此发生） │ │ │ │ must / filter should │ │ "都得满足" "取最高分" │ │ │ │ │ │ 合取路径 析取路径 │ │ cost 排序 WAND 剪枝 │ │ 最稀疏领头 高分优先推进 │ │ │ │ │ │ 上篇 §五 下篇全文 │ └──────────────────────────────────────┘

对应到文字，三道工序是：

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

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

顺带提一个容易忽略的回流：should 本来走右边的析取路径，但第二道改写里有条规则——当 should 的数量恰好等于 minimum_should_match 时，会把它们全部转成 must（见 §四规则三），于是又回到左边的合取路径。所以图里这条"分流"不是一成不变的，改写层有可能把子句从右边挪到左边。

本篇讲前两道工序，加上第三道里合取查询（must / filter）的部分。析取路径（should）留给下篇。

三、第一道工序：结构合法化，不碰顺序

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

它会做几类"修补"：

• 空查询处理：如果整个 bool 查询为空，退化成"匹配全部文档"；如果某个 must / filter 子句注定匹配不到文档，整个查询直接返回空结果，省得白跑一趟。
• 纯否定查询补全：如果查询只有 must_not、没有任何正向条件，引擎不知道"从哪些文档里排除"，于是自动补一个"全部文档"作为基础集合。这个修补默认开启。
• 解析 minimum_should_match：把你写的"2"、"75%"、"3<75%"等规格字符串，转成引擎认识的整数。

一句话：Easysearch 层不改变子句顺序，只做合法化修补。

四、第二道工序：自动改写查询形态

查询进入 Lucene 后，会经过一轮"逻辑等价改写"——不改结果，只改形态，为后续执行铺路。这一层有十几条规则，大部分是"打扫卫生"式的防御性规则（去重、删矛盾、删冗余），不必逐条记忆。我们只需要了解几条对性能影响较大的。

规则一：同一个条件既是"可选"又是"必选"，就升级为"必选"

如果同一个子查询同时出现在 should 和 filter 里，引擎会把它从 should 提升为 must。

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

优化前： 优化后： SHOULD: [term:A] MUST: [term:A] ← 提升了 FILTER: [term:A] SHOULD: [term:B] SHOULD: [term:B]

这一条很关键，它直接改变了执行路径：提升后，这个条件从一个"可选加分"的角色，进入更高效的合取路径。

规则二：把嵌套的 should 拍平

如果 should 里又套了一个全是 should 的 bool，引擎会把内层子句全部提升到外层，变成同级。

优化前： 优化后： SHOULD: term:A SHOULD: term:A SHOULD: (内层 bool) SHOULD: term:B SHOULD: term:B SHOULD: term:C SHOULD: term:C

💡 为什么要拍平？拍平后，引擎能看清每个子句各自能贡献多少分，估算更紧，剪枝更狠。不拍平的话，内层 bool 是个黑盒，引擎只能按它最宽松的上界估，剪不动。下篇讲析取剪枝时会用到这点。

规则三：should 数量恰好等于 minimum_should_match，全部升级为 must

should: [A, B, C]，minimum_should_match: 3 ↓ 等价于"三个都得满足" must: [A, B, C]

💡 类比：开会时如果"3 个可选发言人必须全部到场"，那"可选"就没意义了，等价于"3 个必须到场"。

这条规则在动态拼接查询时经常悄悄帮你：比如你把用户的多个筛选条件塞进 should，又把 minimum_should_match 设成条件数，引擎会自动转成更高效的 must 查询，无需手动改写。

规则四：重复子句合并权重

should 或 must 里出现相同子句时，引擎会把它们的权重相加合并，而不是各跑一遍。

should: [hello^1.5, hello^2.0, world] → should: [hello^3.5, world]

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

除这几条外，其余规则大多是去重、删矛盾、删冗余这类"打扫卫生"，理解大意即可。

一条改写如何改变执行路径

看个具体例子：

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

status:published同时出现在 should 和 filter——规则一会把它提升为 must。优化前后对比：

没有优化（假设）： 优化后（实际）： status:published 出现两次： status:published 只出现一次： • filter 里遍历一遍（只过滤） • 作为 must，一次迭代同时 • should 里再遍历一遍（评分） 完成过滤和评分 = 同一个词被两个迭代器各跑一遍，浪费

一条改写规则，改变了执行路径的选择。它不做代价排序，但决定了哪些子句有资格走更高效的路径。

五、第三道工序（合取部分）：让最稀疏的条件领跑

进入执行层后，每个 must / filter 子句会变成一个"文档迭代器"——你可以理解成这个条件对应的匹配文档列表的游标，负责告诉引擎"下一个匹配的文档号是谁"。

合取查询（must / filter，AND 语义）的核心优化是：按 cost 排序，让匹配文档最少的迭代器领头。

生活类比

找"已签收、发往北京、备注里有易碎品"的包裹。"已签收"和"发往北京"的包裹可能很多，但"备注里有易碎品"的很少。先从"易碎品"开始查，再确认它是否发往北京、是否已签收，比先遍历所有已签收包裹更快。

在 AND 查询里，谁的结果最少，谁最有"话语权"——因为所有条件都得满足，结果最少的那个条件能最快排除不满足的文档，其余条件只需确认即可。

执行过程

引擎把所有迭代器按 cost（预估匹配文档数）从小到大排序：

• 领头（lead1）：代价最小的迭代器，负责领头，它最稀疏，每次跳转跳过的文档最多。
• 第二（lead2）：代价第二小的，负责二次确认。
• 其余：只在领头、第二都停下时才被调用。

执行就是"不断对齐"：领头停在某个文档号，第二个跳过去看在不在这；如果第二个跳过了，说明这个文档不匹配，领头直接跳到第二个的位置继续——不会去逐个检查中间那些文档。

把三个迭代器画出来，按 cost 从小到大排好，对齐过程一目了然：

迭代器（按 cost 升序） 命中的 docID（升序） 游标 ┌──────────────────┐ │ author:sam 500篇 │ ··· 42 ── 78 ── 203 ── ··· ▼ lead1 领头 └──────────────────┘ ┌──────────────────┐ │ category:ai 1万 │ ··· 42 ──────── 203 ── ··· ▼ lead2 确认 └──────────────────┘ ┌──────────────────┐ │ status:pub 100万 │ ··· 42 ── 78 ── ··· ── 203 ── ▼ others 兜底 └──────────────────┘ ───────────────────────────────────────────→ docID 轴 42 78 203 领头跳到 42 → lead2 在 42 ✓ → others 在 42 ✓ → 三者对齐，匹配！ 领头跳到 78 → lead2 advance(78) 落在 203（>78，没命中）→ 领头跳到 203 领头跳到 203 → lead2 在 203 ✓ → others 追到 203 ✓ → 匹配！ 78 这篇 lead2 不在，直接跳过，others 根本没被叫起来

查询：must: [status:published(100万), category:ai(1万), author:sam(500)] 排序后： 领头: author:sam 500 篇 ← 最稀疏，领头 第二: category:ai 1万篇 其余: status:published 100万篇 领头 → doc=42 → 第二确认✓ → 其余确认✓ → 匹配！ 领头 → doc=78 → 第二确认✗ → 跳过（其余根本不用查） 领头 → doc=203 → 第二确认✓ → 其余确认✓ → 匹配！

如果反过来让高频词领头，后面条件就得确认一大堆无效文档——慢。这就是为什么引擎要按 cost 重排，而不是用你写的顺序。

一个延伸：验证也要按成本排序

有些查询是"两阶段"的——先粗筛出可能匹配的文档，再精确验证。比如短语查询：先找到"包含全部词"的文档，再检查这些词的相对位置对不对。引擎会让便宜的验证先做，失败就直接短路。

💡 类比：先查身份证（快），再查指纹（慢），而不是反过来。身份证不对，指纹根本不用查。

六、用 Profile API 观察

理论不如动手跑。Easysearch 的 Profile API 能直接暴露改写后的查询形态。准备一个含 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 的查询描述里，+表示 must，没有符号表示 should。status:published前面有+，说明改写已经把它提升为 must 了。

description三个符号速查：

再看一个例子：把 must 顺序反过来

上面看的是改写规则。再看 cost 排序的实证——用一个最简单的两个 must 查询，故意把高频词写前面：

GET/products/_search{"profile":true,"query":{"bool":{"must":[{"term":{"status":"published"}},// 约 900 篇{"term":{"category":"ai"}}// 约 100 篇]}}}

在测试索引里status:published约 900 篇、category:ai约 100 篇。实测 profile 的子节点（Easysearch 2.2.0）：

category:ai命中少，成了领头，不断用nextDoc()产生候选；status:published命中多，只跟在后面用advance()确认——和你在 JSON 里把谁写在前面完全无关。

把两个 must 的顺序对调再查，profile 结果一模一样：category:ai仍然是领头，status:published仍然跟随。description字段会保留你写的展示顺序（先status后category），但真正执行时的迭代器顺序由 cost 排序决定。

这就是本篇强调那句话的实证：用户在 JSON 里先写谁，不等于执行时谁先跑。

七、本篇要点：写查询时该注意什么

既然子句顺序不影响性能，那写查询时该关注什么？

✅ 用 filter 代替 must，当不需要评分时

filter 不参与评分，走更高效的路径，也不会增加评分子句的调度开销。需要过滤但不需要算相关性分数时，用 filter。

✅ 不必手动把 should 改成 must

当 should 数量恰好等于 minimum_should_match 时，引擎会自动把所有 should 提升为 must。只要语义等价，引擎会替你做正确的选择，不用手动"帮"它。

✅ 避免嵌套过深的布尔查询

should 里嵌套 should 时，尽量手动拍平或让引擎自动拍平。嵌套结构会让引擎看不清内层子句，估算偏松，剪枝打折。

❌ 不必刻意调整子句顺序

底层会自动按 cost（合取）或 maxScore（析取）排序。先写高频词还是低频词，执行时的迭代顺序完全相同。

✅ 理解 cost 的含义

cost 是"匹配文档数的估算"，不是执行时间。一个高 cost 的 term 查询可能因为倒排表连续存储而很快，一个低 cost 的范围查询反而可能要更贵的验证。Profile 里的 advance 次数才是真实性能的反映。

🔍 想翻源码：合取路径的选型和 cost 排序在 Lucene 的Boolean2ScorerSupplier（决定走哪条路）和ConjunctionDISI（构造时对迭代器按cost()排序，代价最小的领头）。

下篇预告

本篇讲的是"所有条件都得满足"的合取查询——谁最少谁领头。下篇讲析取（should）场景：不需要全部匹配，而是找分数最高的 K 个文档。优化目标从"最少匹配"变成"最高分数"，引擎会换一套完全不同的剪枝策略——WAND 算法登场，并且有一个开关（track_total_hits）决定剪枝开不开。