本节书摘来华章计算机《深入理解Elasticsearch（原书第2版）》一书中的第2章 ，第2.4.4节，[美]拉斐尔·酷奇（Rafal Ku） 马雷克·罗戈任斯基（Marek Rogoziski）著 张世武 余洪淼 商旦 译 更多章节内容可以访问云栖社区“华章计算机”公众号查看。
2.4.4 后置过滤和过滤查询
如果某人说过滤比实现相同功能的查询执行更快，这不一定是真的。的确，过滤器需要考虑的东西更少，并且可以在后续查询中复用，不过Lucene早就针对查询做了高度优化，以确保查询能够高速执行，甚至在考虑文档评分的情境下。当然，如果匹配结果数量极多，过滤器会执行得更快一些。不过，还有一些事我们没有告诉你。某些时候，在使用后置过滤（post_filter）时，Elasticsearch查询的执行速度没有我们期望的那么快。假如我们执行如下查询：
下图展示了查询的执行过程：
当然，针对大量数据的过滤是很有价值的。不过在本例中，我们使用现有的少量数据。从上图可见，索引中包含4个文档。例子中的terms查询匹配了3个文档：Doc1、Doc3和Doc4。每个匹配的文档都被计算得分并根据得分做了排序。之后，post_filter开始工作。在索引的所有文档中，它只通过了两个文档：Doc1和Doc4。可以看到，一共传递给过滤器3个文档，而只有其中的两个被作为结果输出。既然如此，还有必要对Doc3计算得分吗？本例我们浪费了一部分CPU时间来计算一个最终不匹配的文档的得分。如果类似的文档数量很多，这将是一个性能问题。
本例中我们使用了term过滤器。该过滤器在Elasticsearch 1.5版本之前都是默认缓存的。而从1.5版本开始，默认不再缓存（参考https://github.com/Elasticsearch/Elasticsearch/pull/7583）。因此，我们在例子中使用term过滤器时特意使用了强制缓存。
让我们修改一下这个查询，让文档过滤操作发生在Scorer计算文档得分之前。修改后的查询如下：
在这里我们使用了过滤查询（filtered query）。返回的查询结果和前一个查询一模一样，不过执行过程稍微有一些变化，特别是在执行过滤操作时。下图揭示了这个查询在理论上的执行过程：
现在，最初的工作是由term过滤器完成的。如果这个过滤器在之前被使用过，它将从缓存中加载，整个文档集合将被筛成只剩两个文档。最后，这两个文档仍然需要被计算得分，不过评分模块需要做的工作少了一些。当然，本例中，查询和过滤后的文档相匹配，不过这一点并非在所有查询场景下都满足。
从技巧上看，我们让过滤器被一个查询所包裹，让Lucene库能够只收集被过滤通过的结果。当然，过滤通过的结果还需要被传递给主查询做进一步处理。多亏了过滤器，打分程序需要处理的文档数量减少了。
