Lucene v7.2主键字段定义与文档查询性能优化问询

嘿，作为Lucene新手能关注到唯一ID查询的性能细节，这点很棒！我来逐个解答你的疑问，帮你把这个查询的性能拉满：

你的基础方案（StringField存ID + TermQuery查询）已经是Lucene里最适合精确匹配唯一ID的方式了，几个小优化点能让它更高效：

• 复用Term对象：每次查询都new Term("uid", uid)会产生不必要的对象创建开销，高并发场景下更明显。建议缓存常用的Term实例，或者每个线程维护一个可复用的Term（比如用Term.set()方法重置值）。
• 按需加载字段：如果你不需要完整的文档内容，查询后调用searcher.doc(docID, Collections.singleton("uid"))（或者你需要的其他字段），只加载必要的存储字段，减少磁盘IO和内存消耗。
• 跳过不必要的打分：TermQuery本身是精确匹配，你可以用BooleanQuery把它包装成过滤条件（Occur.FILTER），或者直接调用searcher.search(query, 1, Sort.INDEXORDER)，跳过打分环节，节省一点CPU资源。
• 合并索引段：如果索引频繁更新，定期在低峰期执行IndexWriter.forceMerge(1)把索引合并成单个段，这样Term查询时不需要遍历多个段，能提升查询速度。

有差异，但主要体现在存储成本和易用性上，查询性能差异极小：

• 存储体积：比如UUID作为字符串是36个字符（UTF-8下占36字节），转成字节数组只需要16字节，能显著减少索引的磁盘占用，间接降低IO开销。
• 查询性能：Lucene内部处理字符串时都会转成BytesRef，字节数组版本相当于跳过了字符串到BytesRef的转换步骤，性能提升微乎其微，几乎感知不到。
• 易用性：字符串版本更直观，处理起来不需要额外的编解码逻辑，不容易出错。除非你的索引规模极大（比如数亿级文档），追求极致的存储空间，否则字符串版本完全够用。

• 编解码器：Lucene 7.2默认的Lucene72Codec已经对Term查询做了充分优化，不需要更换特殊编解码器。如果想压缩索引体积，可以试试CompressingCodec，它能减少磁盘占用，但会带来一点压缩/解压的CPU开销，需要根据你的硬件情况权衡。
• 过滤器：针对唯一ID查询，过滤器的作用非常有限——因为TermQuery本身就是精确匹配，结果集最多只有1个文档，过滤操作没有意义。硬要说的话，如果你有大量重复的相同ID查询，可以用CachingWrapperFilter缓存查询结果，但收益极低，通常没必要。

完全不用担心O(n)的情况！Lucene的倒排索引用了FST（有限状态转换器）来存储Term字典，根据Term查找对应的文档ID的时间复杂度是O(log m)（m是该字段的Term总数），和总文档数n无关。

简单说，Lucene会把所有uid字段的Term按字典序排序并用FST高效存储，查找时通过快速匹配直接定位到对应的Term，然后拿到关联的文档ID（对于唯一ID来说，这个关联列表只有一个元素）。哪怕你有上亿文档，唯一ID的查询速度依然非常稳定，不会随文档数量线性增长。

内容的提问来源于stack exchange，提问作者xpages-noob