我有 Lucene .Net 索引（目前正在运行 2.9.2 版，但我将很快升级到新的 3.0.3）。
对于搜索性能问题，我需要创建从 DocId 到 Application Id 的内存映射 - 所以我不需要从索引中获取存储的值（搜索结果可能会返回数千个文档......）。由于我有很多索引迭代，我需要多次更新\重新创建这个映射 - 所以我需要快速完成。
我看到这篇很棒的文章试图解决这个问题，并通过使用 Lucene 的FieldCache机制检索结果或TermPositions在唯一索引字段上使用枚举来比较时间。正如作者所说，确实使用 Lucene 创建映射TermPositions要快得多FieldCache，但理解为什么对我来说非常重要。有人可以向我解释一下两者TermPositions在FieldCache幕后做什么吗？
原因很简单。Lucene 将字段值存储为字符串。当您调用GetInts并且值不在缓存中时，它需要读取字符串，然后将它们解析为整数。
当您使用有效负载时，您会将整数编码为字节数组，然后再转换回整数。这样，您只需要求 Lucene 在给定位置读取 4 个原始字节，然后将其转换回 int。
字符串读取/解析操作在这里有很大的不同
Lucene 中的 TermPositions 是一项高级功能。我只用过一次（像你一样从 2.9.x 迁移到 3.0.3 RC2 时）。TermPositions 使用 Tuple 非常有效地存储，这使得作为数据结构的访问速度很快，而且它很小，因此检索带有术语“位置”的有效负载也很快。
实际上，我最终浏览了名为“Lucene in Action”的书中的示例……它适用于 Java，但它基于 Lucene 3.0.3，非常适合 Lucene.NET 3.0.3 :)
我提到这一点，因为 FieldCache 在那本书中涉及的很深，如果你想深入了解（深入了解它）......我会先看看那里。
顺便说一句...那篇文章基于 Lucene 2.2，2.3->2.9.x 是一个相当大的飞跃，因为他们添加了“近乎实时的搜索”并使很多方法过时...3.0.3 也改变了这一点，所以他们的数字可能无法反映正在发生的事情。