Rails+Mongoid嵌套集：多OR索引条件组合后查询性能是否高效？

我们的系统基于Rails和Mongoid实现，帖子支持任意层级的评论，因此采用**嵌套集（Nested Set）**模式。需对帖子的顶级评论进行分页，示例代码如下：

comments = post.comments.page(1).per(10)

假设第一页的评论为comment1至comment10，查询这些评论的所有子孙评论时，使用的语句为：

all_comments = Comment.where(:lft.gte => comment1.lft, :lft.lte => comment1.rgt)
  .or(Comment.where(:lft.gte => comment2.lft, :lft.lte => comment2.rgt))
  ...
  .or(Comment.where(:lft.gte => comment10.lft, :lft.lte => comment10.rgt))

单个条件查询会走索引扫描，但将多个此类条件用OR组合后，查询是否仍能保持高性能？对应的SQL语句如下：

select * from comments WHERE (lft >= 10 and lft<=20 OR lft >= 30 and lft<=40 OR...)

对应的执行计划（EXPLAIN）结果为：

Bitmap Heap Scan on comments  (cost=12.55..23.20 rows=9 width=100)
   Recheck Cond: (((lft >= 1) AND (lft <= 8)) OR ((lft >= 9) AND (lft <= 16)) OR ((lft >= 17) AND (lft <= 24)))
   ->  BitmapOr  (cost=12.55..12.55 rows=9 width=0)
         ->  Bitmap Index Scan on index_comments_on_lft  (cost=0.00..4.18 rows=3 width=0)
               Index Cond: ((lft >= 1) AND (lft <= 8))
         ->  Bitmap Index Scan on index_comments_on_lft  (cost=0.00..4.18 rows=3 width=0)
               Index Cond: ((lft >= 9) AND (lft <= 16))
         ->  Bitmap Index Scan on index_comments_on_lft  (cost=0.00..4.18 rows=3 width=0)
               Index Cond: ((lft >= 17) AND (lft <= 24))
(9 rows)

结论：该查询仍能保持高性能 #

从执行计划可以明确看到：

• 每个OR分支都单独触发了index_comments_on_lft索引的Bitmap Index Scan，所有区间条件都充分利用了索引定位数据；
• 数据库通过BitmapOr操作合并多个索引扫描的结果，最后执行Bitmap Heap Scan取出实际数据；
• 这种方式完全避免了全表扫描，单个子条件的索引扫描成本极低，合并后的总体成本也处于可控范围。

对于分页场景下的10个左右的OR条件，性能不会有明显下降；即使扩展到数十个条件，只要每个区间都能命中索引，查询效率依然稳定。只有当OR条件数量达到上百级时，Bitmap合并的成本才会有所上升，但这在常规分页场景中几乎不会出现。

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