1. 问题的起点：用户还没打完字
搜索框里的输入是一个不完整的字符串 。当用户敲到 quick brown f 时，前两个词已经输入完毕、语义确定，最后那个 f 是一个"正在生长中"的词。任何把 f 当作完整词项去查倒排索引的做法都会命中零结果，因为索引里存的是 fox、from、file，没有 f。
Elasticsearch 提供了两个专门处理这个场景的查询：
| 查询 | 引入版本 | 一句话概括 |
|---|---|---|
match_phrase_prefix |
很早（1.x 时代即有） | 短语匹配，但允许最后一个词是前缀 |
match_bool_prefix |
7.2 | 布尔匹配，把词打散成 should，其中最后一个词是前缀 |
它们的名字只差一个词，行为差异却相当大：一个要求词序与相邻性，一个完全不管顺序。选错会直接导致召回过低或精度崩塌。下面逐层拆解。
2. 前置知识：搞清"前缀"到底作用在哪一层
在讨论这两个查询之前，必须先明确三件事，否则后面的所有行为都会显得很随机。
2.1 前缀作用于"分词后的词项"，而不是原始字符串
假设字段用 standard analyzer，查询字符串是 quick brown f：
"quick brown f"
↓ standard analyzer
["quick", "brown", "f"]
↓ 两个查询的共同第一步
前 n-1 个词 → 精确词项（term）
最后 1 个词 → 前缀（prefix）所以 quick 和 brown 必须在索引里精确存在 （经过同一 analyzer 处理后）。如果用户输入 quick browns f，browns 在没有词干化的情况下就是精确匹配失败，整个查询直接落空。这一点常被误解为"前缀查询很宽松"，实际上它只对最后一个词宽松。
2.2 prefix 查询的代价来自词典枚举
Lucene 的 PrefixQuery 需要在词典（term dictionary，FST 结构）里定位到前缀起点，然后枚举所有以该前缀开头的词项 ，把它们展开成一个多词项查询。前缀越短，展开的词项越多，代价越高。单字符前缀在大字段上是灾难级操作，这也是 max_expansions 存在的根本原因。
2.3 短语匹配需要 position 信息
match_phrase_prefix 属于短语类查询，依赖倒排索引里的位置信息。如果字段映射把 index_options 设成了 docs 或 freqs，多词短语查询会直接抛错：
json
{
"type": "illegal_state_exception",
"reason": "field \"title\" was indexed without position data; cannot run PhraseQuery"
}match_bool_prefix 不需要 position，因此对 index_options 无要求。这是两者在映射兼容性上的第一个硬差异。
3. match_phrase_prefix 全解
3.1 基本语法
json
GET /articles/_search
{
"query": {
"match_phrase_prefix": {
"title": {
"query": "quick brown f",
"analyzer": "standard",
"max_expansions": 50,
"slop": 0,
"zero_terms_query": "none"
}
}
}
}简写形式（全部参数取默认值）：
json
{ "query": { "match_phrase_prefix": { "title": "quick brown f" } } }3.2 执行流程
输入: "quick brown f"
│
├─ Step 1 用 search_analyzer（默认与字段 analyzer 一致）分词
│ → ["quick", "brown", "f"]
│
├─ Step 2 在词典中枚举以 "f" 开头的词项，最多 max_expansions 个
│ → ["fox", "for", "from", "file", "final", ...]
│
├─ Step 3 构造 MultiPhrasePrefixQuery
│ position 0: {quick}
│ position 1: {brown}
│ position 2: {fox, for, from, file, final, ...} ← 该位置任一命中即可
│
└─ Step 4 按 slop 允许的位置容差做短语匹配，命中后按短语频次打分关键点：position 2 上的候选词是"或"关系，但位置约束仍然生效 。也就是说文档必须存在这样一段：quick 紧跟 brown，brown 紧跟一个以 f 开头的词。
在 Elasticsearch 源码中，这一步构造的是 org.elasticsearch.lucene.queries.MultiPhrasePrefixQuery（早期包路径为 org.elasticsearch.common.lucene.search），它是对 Lucene MultiPhraseQuery 的扩展，专门允许最后一个 position 携带前缀展开集合。可以用 _validate/query 直接看到重写后的查询：
json
GET /articles/_validate/query?rewrite=true&explain=true
{
"query": { "match_phrase_prefix": { "title": "quick brown f" } }
}返回的 explanation 会显示类似 title:"quick brown f*" 的形式，profile API 里则能看到 MultiPhrasePrefixQuery 的实际耗时构成。
3.3 参数详解
query（必填）
待匹配的文本。最后一个词按前缀处理，其余按精确词项处理。
analyzer
覆盖字段默认的搜索分词器。改这个参数要非常小心：查询分词器必须与索引分词器产出可对齐的词项，否则前 n-1 个精确词永远匹配不上。
max_expansions（默认 50）
最后一个词最多展开成多少个词项。这个参数的真实语义远比文档字面复杂，单独开一节讲。
slop（默认 0）
允许的词项位置偏移总量，用于容忍插入词和词序颠倒。
json
{ "match_phrase_prefix": { "title": { "query": "quick f", "slop": 1 } } }slop: 0：quick与f*必须严格相邻且顺序一致。slop: 1：可以匹配quick brown fox（中间隔了一个词，位移 1）。slop: 2：还能匹配词序颠倒（交换相邻两词需要 2 个位移单位）。
需要注意，slop 是位移预算总和，不是"允许几个词插入"。多处小偏移会累加消耗预算。
zero_terms_query（默认 none）
当分词后词项为空时（例如查询字符串全是停用词，且 analyzer 配了 stop filter）的降级行为：
none：返回零结果。all：等价于match_all。
搜索框补全场景通常保持 none，避免用户误敲一个 the 就返回全库数据。
3.4 max_expansions 的真相（最重要的一节）
大多数生产事故都出在这里。三条容易被忽略的事实：
事实一：截断发生在分片级别。 max_expansions 在每个分片上独立生效。5 个分片、max_expansions: 50，意味着最多可能有 250 个不同词项参与匹配，但每个分片各自只看自己词典里的前 50 个。这导致同一个查询在不同分片数、不同数据分布下的召回结果不一致，测试环境（单分片）正常、生产环境（多分片）漏结果是典型症状。
事实二：截断顺序是词典字节序，不是相关性。 枚举按 UTF-8 字节序进行，取"字典序最靠前的 N 个"，与词频、相关性、文档数量完全无关。构造一个能稳定复现的例子：
json
PUT /demo_expansions
{ "settings": { "number_of_shards": 1 } }
// 批量写入 app1 ~ app100 共 100 个词项，外加 application
POST /demo_expansions/_bulk
{"index":{}}
{"name":"my app1"}
{"index":{}}
{"name":"my app2"}
... （中略，写到 app100）
{"index":{}}
{"name":"my application"}词典中以 app 开头的词项按字节序排列是：
app1, app10, app100, app11, app12, ..., app19, app2, app20, ...application 在字节序上排在 app99 之后（因为字母 l 的字节值大于所有数字），排位远超第 50 位。于是：
json
GET /demo_expansions/_search
{
"query": {
"match_phrase_prefix": { "name": { "query": "my app", "max_expansions": 50 } }
}
}搜不到 my application 。而把 max_expansions 调到 200，或者把查询改成 my appl（前缀变长，展开集合变小），立刻就能命中。这就是"明明有这条数据，为什么搜不出来"的标准答案。
事实三：调大 max_expansions 不是解药。 每多一个展开词项，短语匹配就要多读一份 position 列表并参与位置合并。max_expansions 从 50 提到 5000 会让延迟以肉眼可见的幅度上涨，而且仍然不能保证覆盖。Elasticsearch 官方文档对此的态度很明确：match_phrase_prefix 适合临时性、低要求的前缀短语匹配，不推荐作为正式的 search-as-you-type 方案，正规做法是把代价挪到索引期（见第 7 节）。
3.5 match_phrase_prefix 的坑清单
| 现象 | 原因 | 处理 |
|---|---|---|
| 数据存在但搜不到 | max_expansions 字节序截断 |
加长前缀触发阈值、改用索引期方案 |
| 单分片正常、多分片漏 | 分片级独立截断 | 同上；勿用分片数掩盖问题 |
| 换词序就没结果 | 短语查询顺序敏感 | 调 slop，或换 match_bool_prefix |
报 without position data |
index_options 不含 positions |
修映射并 reindex |
| 前面的词打错一个字母就全空 | 前 n-1 个词是精确匹配，不支持 fuzziness |
用 match_bool_prefix（支持 fuzziness）或加纠错层 |
| 用户输入末尾带空格后行为变化 | 末尾空格不产生新词项，最后一个完整词仍按前缀处理 | 一般无害（词是自身的前缀），但要在测试用例里覆盖 |
对 keyword 字段行为怪异 |
keyword 整个值是一个词项，退化为整值前缀匹配，且大小写敏感 |
明确是否需要整值前缀语义；需要则配 normalizer |
4. match_bool_prefix 全解
4.1 基本语法
json
GET /articles/_search
{
"query": {
"match_bool_prefix": {
"title": {
"query": "quick brown f",
"analyzer": "standard",
"operator": "or",
"minimum_should_match": "2",
"fuzziness": "AUTO",
"prefix_length": 1,
"max_expansions": 50,
"fuzzy_transpositions": true,
"fuzzy_rewrite": "constant_score_blended"
}
}
}
}4.2 执行流程
输入: "quick brown f"
│
├─ Step 1 分词 → ["quick", "brown", "f"]
│
├─ Step 2 前 n-1 个词 → term query
│ 最后 1 个词 → prefix query
│
└─ Step 3 全部塞进一个 bool 查询
{
"bool": {
"should": [
{ "term": { "title": "quick" } },
{ "term": { "title": "brown" } },
{ "prefix": { "title": "f" } }
]
}
}它就是这么一个"语法糖"。没有 position 约束，没有顺序要求，没有相邻性要求。词项散落在文档任何位置都算命中，命中越多分越高。
理解这一点，match_bool_prefix 的所有行为都变得可预测：它等价于 match，只是把最后一个词换成了前缀子句。
4.3 参数详解
operator（默认 or）
控制 bool 子句的组合方式。and 时全部子句变成 must（包含最后那个前缀子句）：
json
{
"match_bool_prefix": {
"title": { "query": "quick brown f", "operator": "and" }
}
}等价于三个子句全部必须命中。补全场景通常用 and 或较高的 minimum_should_match，否则精度会崩（见 5.2 节实测）。
minimum_should_match
支持全部标准写法："2"、"75%"、"2<-25%" 等。比 operator 更细腻，是精度与召回之间的主要调节旋钮。推荐给渐进式补全用相对值（如 "75%"），这样用户输入越多、约束越强。
fuzziness 系列（match_phrase_prefix 完全不支持）
fuzziness、prefix_length、fuzzy_transpositions、fuzzy_rewrite 只作用在前 n-1 个完整词项 上，把它们从 term 查询升级为 fuzzy 查询。最后那个前缀词不参与模糊（前缀本身已经足够宽松，再叠加编辑距离会造成语义爆炸）。
这带来一个很实用的能力：用户前面打错字也能召回。
json
{
"match_bool_prefix": {
"title": { "query": "quik brown f", "fuzziness": "AUTO" }
}
}quik 通过编辑距离 1 匹配到 quick，整个查询依然工作。这是 match_phrase_prefix 做不到的。
⚠️ max_expansions 在这里换了含义
这是两个查询最隐蔽的参数陷阱：
| 查询 | max_expansions 控制什么 |
|---|---|
match_phrase_prefix |
最后一个词的前缀展开上限 |
match_bool_prefix |
前 n-1 个词的模糊变体上限（属于 fuzziness 参数族） |
也就是说，在 match_bool_prefix 里调 max_expansions 不会 影响最后那个前缀子句的展开行为。前缀子句就是一个标准 prefix 查询，它的成本由前缀长度和词典分布决定，没有独立的 max_expansions 阈门。
好消息是这意味着 match_bool_prefix 不存在"字典序截断导致漏数据"的问题 （3.4 事实二那个 application 的例子在 match_bool_prefix 下能正常召回）。代价是它对超短前缀的性能保护更弱，需要在应用层限制最短触发长度。
4.4 match_bool_prefix 的坑清单
| 现象 | 原因 | 处理 |
|---|---|---|
| 返回大量不相关结果 | 默认 or，命中任一词即返回 |
设 operator: and 或 minimum_should_match |
| 短语意图被破坏（"张三"匹到含"三"和"张"的无关文档） | 无顺序、无相邻约束 | 用 match_phrase_prefix，或与之组合打分 |
| 单字符输入时查询极慢 | 前缀子句无 max_expansions 保护 |
应用层要求 ≥2~3 字符再发请求；启用 index_prefixes |
| 相关性排序不符合直觉 | 前缀子句常量打分（见第 6 节） | 用 bool 组合 rescore，或改索引期方案 |
5. 正面对比：同一份数据，两种结果
5.1 构造实验环境
json
PUT /prefix_demo
{
"settings": { "number_of_shards": 1 },
"mappings": {
"properties": {
"title": { "type": "text", "analyzer": "standard" }
}
}
}
POST /prefix_demo/_bulk?refresh
{"index":{"_id":"1"}}
{"title":"quick brown fox jumps over the lazy dog"}
{"index":{"_id":"2"}}
{"title":"brown quick fox"}
{"index":{"_id":"3"}}
{"title":"quick fox is brown"}
{"index":{"_id":"4"}}
{"title":"the quick brownstone building"}
{"index":{"_id":"5"}}
{"title":"quick brown fence"}5.2 查询 "quick brown f" 的结果对照
分词结果：["quick", "brown", "f"]
A. match_phrase_prefix
json
{ "query": { "match_phrase_prefix": { "title": "quick brown f" } } }| 文档 | 内容 | 是否命中 | 原因 |
|---|---|---|---|
| 1 | quick brown fox jumps... | ✅ | quick(0) brown(1) fox(2)，严格相邻同序 |
| 2 | brown quick fox | ❌ | 词序不符，slop: 0 不容忍 |
| 3 | quick fox is brown | ❌ | brown 位置不对 |
| 4 | the quick brownstone building | ❌ | 词项是 brownstone，不等于 brown |
| 5 | quick brown fence | ✅ | fence 命中 f* 前缀 |
结果集：{1, 5} --- 精确，符合"用户在敲一个短语"的意图。
B. match_bool_prefix（默认 or）
json
{ "query": { "match_bool_prefix": { "title": "quick brown f" } } }| 文档 | 命中子句数 | 是否返回 |
|---|---|---|
| 1 | quick + brown + fox(f*) = 3 | ✅ 高分 |
| 2 | quick + brown + fox(f*) = 3 | ✅ 高分（顺序无关！） |
| 3 | quick + brown + fox(f*) = 3 | ✅ 高分 |
| 5 | quick + brown + fence(f*) = 3 | ✅ 高分 |
| 4 | quick = 1（brownstone 不是 brown，也不以 f 开头） |
✅ 低分 |
结果集：{1, 2, 3, 5, 4} --- 全部 5 条 。文档 4 只因为包含一个 quick 就被召回了，这就是默认 or 的精度代价。
C. match_bool_prefix + operator: and
json
{
"query": {
"match_bool_prefix": {
"title": { "query": "quick brown f", "operator": "and" }
}
}
}结果集：{1, 2, 3, 5} --- 剔除了文档 4，但依然不区分词序。这通常是搜索框补全最合适的配置：召回宽松、精度可控。
5.3 能力矩阵
| 维度 | match_phrase_prefix |
match_bool_prefix |
|---|---|---|
| 词序敏感 | ✅ 是 | ❌ 否 |
| 相邻性要求 | ✅ 是（可用 slop 放宽） |
❌ 否 |
| 需要 position 索引 | ✅ 是 | ❌ 否 |
支持 fuzziness |
❌ 否 | ✅ 是（作用于前 n-1 词） |
支持 slop |
✅ 是 | ❌ 否 |
支持 operator / minimum_should_match |
❌ 否 | ✅ 是 |
max_expansions 语义 |
前缀展开上限 | 模糊变体上限 |
| 存在字典序截断漏召回风险 | ⚠️ 有 | 无 |
可利用 index_prefixes 加速 |
一般不能 | 通常可以 |
| 典型延迟 | 较高（位置合并 + 多词项） | 较低（纯布尔） |
| 典型场景 | 短语/地址/书名的顺序敏感补全 | 通用搜索框即时补全 |
5.4 在 multi_match 中的对应类型
两者都有对应的 multi_match 类型，跨字段行为不同：
json
// phrase_prefix：每个字段独立做短语前缀匹配，取最佳字段得分（best_fields 语义）
{
"multi_match": {
"query": "quick brown f",
"type": "phrase_prefix",
"fields": ["title", "body"]
}
}
// bool_prefix：每个字段独立构造 bool 前缀查询，得分按 most_fields 语义累加
{
"multi_match": {
"query": "quick brown f",
"type": "bool_prefix",
"fields": ["title", "title._2gram", "title._3gram"]
}
}bool_prefix 的 most_fields 语义很关键：一个词在多个字段中命中会被重复加分 。这正是 search_as_you_type 字段推荐搭配 bool_prefix 的原因（第 7.2 节）。
6. 打分行为差异：为什么排序看起来"不讲道理"
6.1 match_phrase_prefix 的打分
短语命中后按短语频次（phrase frequency）计算得分，走标准 BM25 路径，字段长度归一化生效。副作用是短文档天然占优 ：标题 quick brown fox 会稳定压过一篇正文里出现同样短语的长文章。这通常是我们想要的。
要注意的是，前缀展开出的多个候选词项在打分时会被合并处理，不同候选词的 IDF 差异不会被忠实反映。也就是说命中 fox（高频词）和命中 fenestration（罕见词）的得分区分度可能低于预期。
6.2 match_bool_prefix 的打分
前 n-1 个 term 子句正常参与 BM25 打分，但最后那个 prefix 子句默认走常量打分路径 （Elasticsearch 的 prefix 查询默认使用 constant-score 类的 rewrite 方法）。后果是：
- 前缀部分对最终排序几乎没有区分贡献，排序主要由前面的完整词决定。
- 用户只输入了一个词的前缀（例如刚敲
f）时，所有命中文档的得分趋于相同，排序退化为近乎随意，看起来"没有相关性"。
实际重写策略随版本演进，不要凭记忆断言。用 profile API 实测确认：
json
GET /prefix_demo/_search
{
"profile": true,
"query": { "match_bool_prefix": { "title": "quick brown f" } }
}在返回的 profile.shards[].searches[].query 中可以看到实际的查询类型（ConstantScoreQuery、BooleanQuery、SynonymQuery 等）与各自的 time_in_nanos。
6.3 工程上的补救：召回与排序分离
想要"召回用前缀、排序讲相关性"，标准做法是把两者拆开：
json
{
"query": {
"bool": {
"must": [
{
"match_bool_prefix": {
"title": { "query": "quick brown f", "operator": "and" }
}
}
],
"should": [
{ "match_phrase": { "title": { "query": "quick brown", "boost": 3 } } },
{ "match": { "title": { "query": "quick brown", "boost": 1 } } }
]
}
}
}must 负责保证召回（含前缀语义），should 用完整词做相关性加权。也可以配合 rescore 只对 top-N 做代价较高的短语打分：
json
{
"query": { "match_bool_prefix": { "title": { "query": "quick brown f", "operator": "and" } } },
"rescore": {
"window_size": 50,
"query": {
"rescore_query": { "match_phrase": { "title": { "query": "quick brown", "slop": 2 } } },
"query_weight": 0.3,
"rescore_query_weight": 1.7
}
}
}7. 第三、第四条路：index_prefixes、search_as_you_type、edge_ngram
前两个查询都把成本放在查询期 。想要更低的延迟和更稳定的召回，就要把成本挪到索引期。
7.1 index_prefixes：给 text 字段加一层前缀加速
json
PUT /articles
{
"mappings": {
"properties": {
"title": {
"type": "text",
"index_prefixes": { "min_chars": 2, "max_chars": 5 }
}
}
}
}Elasticsearch 会为该字段额外建一个隐藏子字段（title._index_prefix），把每个词项的 2~5 字符前缀直接索引成完整词项。此后 prefix 查询在这个长度区间内不再需要枚举词典，直接是一次词项查找。
适用范围要点：
prefix查询与match_bool_prefix的末词前缀子句通常可以自动利用它 （末词前缀走的正是字段类型的prefixQuery路径）。match_phrase_prefix一般无法利用它 ：它需要构造带 position 约束的MultiPhrasePrefixQuery，隐藏子字段的位置信息不能直接套用。所以"加了index_prefixes但match_phrase_prefix没变快"是符合预期的现象，不是配置错误。- 超出
max_chars的前缀会退回普通枚举路径，所以max_chars要覆盖典型输入长度。
务必用 profile API 验证是否真的走到了 _index_prefix 子字段，而不是照抄结论。
7.2 search_as_you_type：官方推荐的补全字段类型
json
PUT /suggest_demo
{
"mappings": {
"properties": {
"title": {
"type": "search_as_you_type",
"max_shingle_size": 3
}
}
}
}这一个映射声明会自动生成四个可查字段：
| 字段 | 内容 | 作用 |
|---|---|---|
title |
原始分词 | 单词匹配 |
title._2gram |
相邻 2 词 shingle | 保留两词邻接关系 |
title._3gram |
相邻 3 词 shingle | 保留三词邻接关系 |
title._index_prefix |
上述词项的边缘前缀 | 前缀直查 |
配套查询就是 bool_prefix：
json
GET /suggest_demo/_search
{
"query": {
"multi_match": {
"query": "quick brown f",
"type": "bool_prefix",
"fields": ["title", "title._2gram", "title._3gram"]
}
}
}这套组合的精妙之处：bool_prefix 本身不管顺序，但 shingle 子字段把"相邻词序"编码进了词项本身。查询词 quick brown 会命中 title._2gram 中的词项 quick brown，而词序颠倒的文档产生的是 brown quick，命中不了。于是在保留 bool_prefix 的宽松召回与低延迟的同时，通过 most_fields 加分机制让词序正确的文档排在前面 。既有召回又有序，这是 match_phrase_prefix 单打独斗做不到的平衡。
代价是索引体积明显增加（原字段 + 2gram + 3gram + 前缀子字段，通常是 3~4 倍量级），且字段不支持排序、聚合能力受限。
7.3 edge_ngram：完全自控的方案
json
PUT /edge_demo
{
"settings": {
"analysis": {
"analyzer": {
"autocomplete_index": {
"tokenizer": "standard",
"filter": ["lowercase", "edge_ngram_filter"]
},
"autocomplete_search": {
"tokenizer": "standard",
"filter": ["lowercase"]
}
},
"filter": {
"edge_ngram_filter": {
"type": "edge_ngram",
"min_gram": 2,
"max_gram": 20
}
}
}
},
"mappings": {
"properties": {
"title": {
"type": "text",
"analyzer": "autocomplete_index",
"search_analyzer": "autocomplete_search"
}
}
}
}索引期切 ngram、查询期不切 ，这是 edge_ngram 方案的铁律。如果查询期也用 autocomplete_index，查询词 fox 会被切成 fo、fox，产生大量噪音召回。
配好后，前缀匹配变成了普通的 match / match_phrase 查询：
json
{ "query": { "match_phrase": { "title": "quick brown f" } } }因为 f 已经是索引里真实存在的词项（fox 的 edge ngram 之一）。这个方案能同时拿到短语顺序约束 + 前缀语义 + 无枚举开销 ，是自建高性能补全的经典做法。缺点是词项膨胀最严重、min_gram/max_gram 需要按业务调、match_phrase 在 ngram 字段上的位置语义需要仔细验证。
7.4 四种方案横向对比
| 方案 | 成本位置 | 顺序敏感 | 索引膨胀 | 召回稳定性 | 适用 |
|---|---|---|---|---|---|
match_phrase_prefix |
查询期 | ✅ | 无 | ⚠️ 受 max_expansions 影响 |
临时需求、低 QPS、字段小 |
match_bool_prefix |
查询期 | ❌ | 无 | ✅ | 通用补全，需配 operator/msm |
search_as_you_type + bool_prefix |
索引期 | ✅（靠 shingle） | 中高 | ✅ | 生产级 search-as-you-type 首选 |
edge_ngram + match_phrase |
索引期 | ✅ | 高 | ✅ | 需要完全自控、极致低延迟 |
另外还有 completion suggester（FST 内存结构，延迟最低、支持权重与上下文过滤），但它是独立的 suggest 端点、不参与常规查询与过滤，适合"下拉候选词"而非"搜结果列表"。两者往往并存：下拉框用 completion suggester，回车后的结果页用 bool_prefix。
8. 性能与容量：代价花在哪里
8.1 成本模型
match_phrase_prefix 成本 ≈ 词典枚举(前缀)
+ Σ(每个展开词项的 postings 读取)
+ 位置列表合并(与 slop、展开数正相关)
match_bool_prefix 成本 ≈ (n-1) × 普通 term 查询
+ 1 × prefix 查询(词典枚举 + postings 归并)短语类查询需要读 position 数据，I/O 与 CPU 都高于纯布尔查询。同样的展开规模下，match_phrase_prefix 通常比 match_bool_prefix 慢一个量级。
8.2 实测建议参数
| 项 | 建议 | 理由 |
|---|---|---|
| 最短触发长度 | ≥ 2（英文）/ ≥ 1~2（中文） | 单字符前缀展开量最大 |
max_expansions（phrase_prefix） |
20~50，不超过 200 | 再大延迟涨得比召回快 |
| 前端防抖 | 150~300ms | 削掉大量中间态请求 |
| 超时保护 | timeout: "200ms" + terminate_after |
补全场景宁可少返回不可卡住 |
| 字段选择 | 只在短字段（title、name）上做前缀 | 长正文字段的词典枚举代价不可控 |
| 分页 | 只取 size: 10~20，禁用深分页 |
补全不需要翻页 |
8.3 一定要用 profile 而不是猜
json
GET /articles/_search
{
"profile": true,
"timeout": "200ms",
"query": { "match_bool_prefix": { "title": { "query": "qu b f", "operator": "and" } } }
}重点看：
query[].type--- 实际重写成了什么（是否用上了_index_prefix）breakdown.build_scorer--- 前缀展开阶段的真实开销，前缀查询的成本主要在这里rewrite_time--- 词典枚举耗时collector--- 排序与收集开销
9. 中文场景的特殊性
英文的"前缀"天然对应"用户正在敲的单词"，中文没有这层结构，直接套用会失效。
9.1 分词粒度决定一切
用 IK 分词器时，北京朝 会被切成什么，完全取决于词典。假设切成 ["北京", "朝"]，那么 match_phrase_prefix 会要求文档中存在 北京 紧跟一个以 朝 开头的词项（如 朝阳），能匹配 北京朝阳区。但如果用户输入 北京朝阳区海 而 海 被切成独立词，行为又变了。中文下的前缀语义高度依赖分词结果的稳定性，输入每多一个字都可能改变整个词项序列。
调试第一步永远是 _analyze：
json
GET /articles/_analyze
{
"analyzer": "ik_smart",
"text": "北京朝"
}9.2 更适合中文的三条路
路线一：edge_ngram 按字切。 对中文用 keyword tokenizer + edge_ngram(min_gram:1)，把 北京朝阳区 索引成 北、北京、北京朝、北京朝... 这样任意长度的前缀输入都是精确词项查找，与分词器无关，行为完全可预测。这是中文即时补全最稳的方案。
路线二：拼音混合。 装 analysis-pinyin 插件，多字段索引汉字 + 全拼 + 首字母，用 bool_prefix 跨这些子字段查询，支持 bj → 北京、beij → 北京 的输入方式。
路线三：ngram（非 edge）用于中间匹配。 中文用户经常从词中间开始输入（"阳区"想找"北京朝阳区"），edge_ngram 无法覆盖，需要完整 ngram。代价是索引膨胀更严重，务必配 index.max_ngram_diff 并控制 min_gram/max_gram 差值。
9.3 search_as_you_type 在中文下的注意点
search_as_you_type 的 shingle 子字段是按词组合的，中文分词后词的数量少、词长不一，2gram/3gram 的收益不如英文明显。它仍然可用，但不要指望复刻英文场景的效果，上线前必须用真实查询日志做召回率评测。
10. 选型决策树
用户输入是否有明确的"短语/顺序"语义？
（地址、书名、人名、商品全称）
│
├─ 是 ──→ 是否是生产级、高 QPS 场景？
│ ├─ 是 ──→ search_as_you_type + multi_match(bool_prefix)
│ │ 或 edge_ngram + match_phrase
│ └─ 否 ──→ match_phrase_prefix（记得压住 max_expansions，
│ 并接受可能漏召回）
│
└─ 否 ──→ 只需要"包含这些词 + 最后一个是前缀"
│
├─ 需要容错拼写 ──→ match_bool_prefix + fuzziness
├─ 需要精度 ──→ match_bool_prefix + operator:and / minimum_should_match
└─ 需要极低延迟 ──→ 字段加 index_prefixes，或改用 completion suggester再补三条经验法则：
- 原型阶段用
match_bool_prefix，上生产改索引期方案。match_bool_prefix零映射改动、行为可预测、无漏召回风险，是最安全的起点。 - 只要发现"数据在但搜不到"，先怀疑
match_phrase_prefix+max_expansions。 这是该查询最高频的故障模式。 - 不要在长正文字段上做任何查询期前缀匹配。 词典规模决定枚举成本，长文本字段的词典是不可控的。
11. 排错手册
Q1：文档明明存在，match_phrase_prefix 就是搜不到。 按顺序排查：① 用 _analyze 确认查询串和文档内容的分词结果能对齐；② 调大 max_expansions 或加长前缀，若立刻命中即为字典序截断（3.4 节）；③ 检查是否多分片导致分片级截断；④ 确认前 n-1 个词是精确匹配，没有单复数/大小写/词干差异。
Q2：match_bool_prefix 返回一堆完全不相关的结果。 默认 operator 是 or，命中任意一个词就返回。加 "operator": "and" 或 "minimum_should_match": "75%"。
Q3：加了 slop 还是匹配不上颠倒词序的文档。 交换相邻两个词需要的位移预算是 2，不是 1。试 "slop": 2。若需要完全忽略顺序，说明该用 match_bool_prefix。
Q4：加了 index_prefixes 但 match_phrase_prefix 没变快。 符合预期。match_phrase_prefix 需要 position 约束，一般无法复用前缀子字段。要享受加速就改用 match_bool_prefix 或 prefix 查询，并用 profile API 确认实际走的查询路径。
Q5：match_phrase_prefix 能不能容错拼写？ 不能，它不支持 fuzziness。需要容错就用 match_bool_prefix（模糊作用于前 n-1 个完整词，最后的前缀词不参与模糊）。
Q6：高亮怎么处理？ unified highlighter 对两者都支持。match_phrase_prefix 会高亮整个短语片段（含前缀命中的完整词），match_bool_prefix 逐词高亮、片段分散。前缀命中的词会被整词高亮（输入 f 会高亮整个 fox），这通常是期望行为。如果高亮结果异常，先确认字段是否配了 term_vector 或 offsets，以及 highlighter 类型是否与查询兼容。
Q7：为什么只输入一个字符时排序完全没有规律？ match_bool_prefix 的前缀子句是常量打分，单词输入时所有文档得分趋同（6.2 节）。用 bool + should 加权或 rescore 引入真实相关性信号（6.3 节）。
Q8：match_bool_prefix 里的 max_expansions 调了没反应。 它在这个查询里属于 fuzziness 参数族，控制模糊变体数量，不控制末词前缀展开（4.3 节）。末词前缀没有独立上限，请在应用层限制最短输入长度。
Q9：怎么确认 ES 实际执行的是什么查询？
json
GET /idx/_validate/query?rewrite=true&explain=true
{ "query": { "match_phrase_prefix": { "title": "quick brown f" } } }配合 "profile": true 的搜索请求，以及针对具体文档的 _explain：
json
GET /idx/_explain/1
{ "query": { "match_bool_prefix": { "title": "quick brown f" } } }12. 速查表
════════════════════════════════════════════════════════════════
match_phrase_prefix
────────────────────────────────────────────────────────────────
构造: 前 n-1 词 = phrase 的固定 position
最后 1 词 = 该 position 上的前缀展开集合（≤ max_expansions）
Lucene: MultiPhrasePrefixQuery
参数: query / analyzer / max_expansions(默认50) / slop(默认0)
/ zero_terms_query(默认none)
要求: 字段必须有 position 信息
特性: 顺序敏感 + 相邻敏感 | 不支持 fuzziness
风险: ⚠️ max_expansions 按字典字节序、分片级截断 → 漏召回
场景: 顺序敏感的短语补全、低 QPS、短字段
════════════════════════════════════════════════════════════════
match_bool_prefix
────────────────────────────────────────────────────────────────
构造: bool.should = [term(w1), ..., term(w_{n-1}), prefix(w_n)]
Lucene: BooleanQuery + PrefixQuery
参数: query / analyzer / operator / minimum_should_match
/ fuzziness / prefix_length / max_expansions*
/ fuzzy_transpositions / fuzzy_rewrite
(*此处控制模糊变体数，非前缀展开数)
要求: 无（不需要 position）
特性: 顺序无关 + 位置无关 | 支持 fuzziness | 前缀子句常量打分
风险: ⚠️ 默认 or 导致精度崩；超短前缀无上限保护
场景: 通用即时搜索；search_as_you_type 的配套查询
════════════════════════════════════════════════════════════════
生产首选
────────────────────────────────────────────────────────────────
type: search_as_you_type + multi_match(type: bool_prefix,
fields: [f, f._2gram, f._3gram])
→ 索引期承担成本，兼顾召回、词序与延迟
════════════════════════════════════════════════════════════════结语
这两个查询的分野可以归到一句话：match_phrase_prefix 保留了短语的结构 ，match_bool_prefix 保留了查询的性能与灵活性 。前者的主要风险是 max_expansions 带来的静默漏召回，后者的主要风险是默认 or 带来的精度崩塌。两者都属于查询期方案，在真实生产流量下都会遇到天花板。
当补全功能从"能用"走向"要好用"时，正确的方向是把成本迁移到索引期：search_as_you_type 是最省心的官方路径，edge_ngram 是控制力最强的自建路径。而 match_phrase_prefix 与 match_bool_prefix 的真正价值，在于让你不改一行映射就能快速验证产品假设，并在排错时准确判断"到底是查询选错了，还是索引建错了"。