Performance 在elasticsearch中，查询上下文是在筛选上下文之前计算的吗？如何确定评估的顺序？

我正在使用以下查询：

GET customer/doc/_search?routing=123
{
  "query": {
    "bool": {
      "filter": [
        {
          "term": {
            "location": "Delhi"
          }
        }
      ],
      "should": [
        {
          "match_phrase_prefix": {
            "phone": {
              "query": "650",
              "max_expansions": 100
            }
          }
        }
      ]
    }
  }
}

问题是我在手机上的搜索不再有效。当我有更少的数据时，它工作得很好，现在每个碎片都有多个位置的数据。手机搜索现在要求我每次输入6到7个字符。（可能存在具有不同位置但位于此碎片上的匹配电话号码）

我猜这是由于max_扩展。当我将其增加到500时，它会返回我的搜索结果（不是全部），但查询速度会变慢

有没有办法强制es先应用过滤器（并限制数据集），然后应用should子句，这样即使使用较小的max_展开值，我也能得到匹配的结果

---

非常感谢您的帮助。

这是由于max_的扩展。限制数据集并不完全是您想要做的事情（这也不是很直截了当——您可能需要使用一些脚本，这反过来会减慢查询速度）

当查询通配符表达式时，Lucene将通配符表达式扩展为反向索引术语词典中的一组实际术语。现在，当你将术语扩展限制为500时，可能会遗漏一些

---

我会考虑在索引阶段使用。前缀有助于避免运行时阶段代价高昂的扩展。

在我的情况下，使用索引前缀有何帮助？我正在使用自定义分析器为电话号码编制索引，该分析器将格式化的号码转换为数字序列。我还需要能够搜索单个数字。尽管，n-gram标记器可能有助于我的情况（尽管存储前缀的成本）-ngram似乎更适合您的目的，因为它不是前缀搜索。