优化啥呢，ES底层用的是Lucene（简称L），最后一定是执行的L代码。
如果你看过ES里search的实现，最后你就会看到这个，
在构造了query对像和这个有点复杂的收集器对像后，就交给L去运行了。
（因为这个search()是L里的方法）
好像ES只要静静地等L完成就行了。后来发现不是，ES还做了一点小改动。
就好比执行的是L的aaa()方法，aaa()里面去执行bbb()方法，
而ES又重写了bbb()方法，所以在这里改动了。
改的目的有两个
1 实现cancellable,就是为了能中止查询
2 就是标题中的优化
如果你看过ES里search的实现，最后你就会看到这个，
在构造了query对像和这个有点复杂的收集器对像后，就交给L去运行了。
（因为这个search()是L里的方法）
好像ES只要静静地等L完成就行了。后来发现不是，ES还做了一点小改动。
就好比执行的是L的aaa()方法，aaa()里面去执行bbb()方法，
而ES又重写了bbb()方法，所以在这里改动了。
改的目的有两个
1 实现cancellable,就是为了能中止查询
2 就是标题中的优化
2 个回复
Charele - Cisco4321
赞同来自: xxwen1217
这个getSparseBitSetOrNull()方法，就是看下live名单，它是不是稀疏类型的，
（如果非稀疏类型就返回null，但并不代表live本身是null）
如果null，就没啥特别的，跟Lucene里执行是一样的。
如果不是null，说明是稀疏的，就执行优化
稀疏就是说，活下来的很少。比如有一万个文档，你删除了9995个，只剩5个了
注意两个红色的不同，都是打分器，一个是BulkScorer，一个是Scorer，
这两个是查询里重要的概念。
（他们名字差不多，初学者可能难理清他们的关系）
Charele - Cisco4321
赞同来自: xxwen1217
红色处，它把live和文档号列表取交集，然后再送给叶收集器。
因为live是稀疏的，所以就预先过滤了大部分的无效文档号，提高了效率。
什么情况会产生稀疏呢，下面来看下。