Lucene从倒排索引中处理已删除文档的机制是什么？

你提到的这种遍历所有词移除文档ID的方式确实成本极高，Lucene根本不会这么做，它的处理逻辑分两个关键阶段：

比如你给出的倒排索引示例：

harry: 1,2,3
potter: 9,10,1
half: 1,6,3

1. 即时标记：不碰倒排索引的轻量操作 #

当删除文档ID=1时，Lucene不会修改任何倒排链的内容，而是在该文档所属的**segment的删除位图（Deleted BitSet）**里，把对应文档ID的位置标记为已删除。

这个位图是独立于倒排索引的轻量结构，标记操作只是简单的位设置，耗时可以忽略。此时查询时，Lucene会先检查这个位图：如果文档被标记删除，就直接过滤掉，用户看不到这条数据。

2. 后台合并：真正清理无效数据 #

只有当Lucene触发segment合并（比如segment数量过多、已删除文档占比过高时自动触发，也可以手动触发），才会真正清理已删除的文档：

• 合并过程中，Lucene会遍历待合并的多个segments，跳过所有被标记为已删除的文档
• 基于剩余的有效文档，重新构建新的segment的倒排索引——这时候新的倒排链里就不会包含已删除的文档ID了（比如harry的倒排链会变成2,3，potter变成9,10）

这种延迟清理的设计，把删除操作的开销降到最低，同时把重负载的清理工作放到后台执行，完全不影响前台的查询和写入性能。

内容的提问来源于stack exchange，提问作者TomSawyer