使用query_string子句搭配模糊运算符时的分析器及Token生成差异问题

问题1：使用query_string子句搭配模糊运算符时，会使用哪种分析器？ #

问题2：为何以下两种查询生成的查询结构（Token逻辑）不同？ #

带模糊运算符的查询 #

查询子句：

{
    "query":
    {
        "query_string": {
            "query": "ads spark~",
            "fields": [
                "flowName",
                "projectName"
            ],
            "default_operator": "and"
        }
    }
}

对应的explain输出：

"explanation": "+(projectName:ads | flowName:ads) +(projectName:spark~1 | flowName:spark~1)"

不带模糊运算符的查询 #

更新后的查询子句：

{
    "query":
    {
        "query_string": {
            "query": "ads spark",
            "fields": [
                "flowName",
                "projectName"
            ],
            "default_operator": "and"
        }
    }
}

对应的explain输出：

"explanation": "(projectName:ads spark | flowName:ads spark)"

解答 #

关于分析器的选择 #

query_string搭配模糊运算符时，会使用每个目标字段自身配置的分析器来处理查询词。比如你指定的flowName和projectName字段，会各自用自己定义的分析器解析对应的查询内容，不会强制使用索引的默认分析器（除非字段未单独配置分析器）。

两种查询结构差异的原因 #

1. 带模糊运算符的场景：
   模糊运算符~是绑定单个词汇的特殊标记，query_string会自动将spark~识别为一个独立的模糊查询单元，同时把ads作为普通查询单元。结合default_operator: "and"，最终生成的逻辑是：必须同时匹配ads（任一目标字段）和spark的模糊匹配结果（任一目标字段），所以拆解成两个独立的OR子查询，再用AND组合。

2. 不带模糊运算符的场景：
   当查询文本是空格分隔的普通词汇且无显式运算符时，在多字段查询场景下，query_string的默认行为是把整个ads spark作为一个短语查询单元，分别对每个目标字段执行短语匹配——也就是查找projectName字段中包含连续ads spark短语的文档，或flowName字段中包含该短语的文档，而非将两个词拆分后按AND逻辑分别匹配每个字段。

内容的提问来源于stack exchange，提问作者Shrikant