Lucene项目中TermQuery在DOCS索引选项下的性能退化问题分析

问题背景

在Apache Lucene 9.12.0版本中，开发者发现了一个关于TermQuery性能的有趣现象：当查询仅使用IndexOptions.DOCS索引选项的字段时，查询性能出现了显著下降。这个问题在后续版本中持续存在，直到10.1.0版本仍未解决。

问题表现

具体表现为：在OpenSearch 2.17（基于Lucene 9.11.1）中，针对"process.name"字段执行term查询"kernel"能在5毫秒内完成，而在OpenSearch 2.18（基于Lucene 9.12.0）中，同样的查询需要200毫秒以上。

技术原理分析

Lucene的查询执行过程中，Collector会在收集到足够数量的匹配结果后设置最小竞争分数(minimum competitive score)。这个设置会告知文档迭代器(DISI)，在后续调用nextDoc时，只返回分数大于等于该最小值的文档。

问题的核心在于ImpactsDISI组件的行为变化。在9.12.0版本后，对于仅使用IndexOptions.DOCS索引的字段，返回的Impact总是DUMMY_IMPACTS。这导致MaxScoreCache计算出的最大分数总是大于最小竞争分数，使得所有文档都被视为竞争性文档，无法进行有效的提前终止优化。

影响范围

这种性能退化特别影响以下场景：

1. 使用TermQuery进行精确匹配查询
2. 查询字段仅配置了IndexOptions.DOCS索引选项
3. 查询结果集较大时性能下降更为明显

解决方案探讨

开发团队提出了几种可能的解决方案：

1. 修改索引选项：将字段索引选项改为DOCS_AND_FREQS，但这会导致索引体积几乎翻倍。

2. 使用ConstantScoreQuery包装：对于不关心评分、仅用作过滤的TermQuery，使用ConstantScoreQuery可以避免此问题，因为它会设置空的delegate，从而实现早期终止。

3. 修改DummyImpacts返回值：在DummyImpacts中返回频率1而非NO_MORE_DOCS。但需要考虑对ExactPhraseMatcher等组件的影响。

4. 不返回DUMMY_IMPACTS：对于IndexOptions.DOCS字段，直接返回实际的Impact信息，而不是使用DUMMY_IMPACTS。这种方法需要谨慎处理相关边界条件。

技术启示

这个问题揭示了Lucene评分机制与索引选项之间的微妙关系。在实际应用中，开发者需要注意：

1. 索引选项的选择不仅影响存储空间，还可能影响查询性能
2. 对于纯过滤场景，考虑使用专门的过滤查询而非评分查询
3. 性能优化需要全面考虑各组件间的交互影响

总结

Lucene的这一性能退化问题展示了搜索引擎底层实现的复杂性。开发者在升级Lucene版本时，不仅需要关注新功能，还需要注意可能存在的性能回归问题。对于使用TermQuery的场景，特别是在仅索引文档ID(DOCS)的情况下，建议评估上述解决方案，选择最适合应用场景的优化方式。