复合索引：跳过前缀与指定前缀全值的查询及性能疑问

背景信息 #

集合结构：

{ 
  field_1: "string", // 仅允许取值"A"或"B"
  field_2: "numeric"
}

已创建复合索引：

{ field_1: 1, field_2: 1 }

原查询语句：

db.col.find( { field_2: { $gt: 100 } } )

修改后查询语句：

db.col.find( { field_1: { $in: ["A", "B"] }, field_2: { $gt: 100 } } )

1. MongoDB会在第二个查询中使用该复合索引吗？ #

会。修改后的查询包含了复合索引的前缀字段field_1，MongoDB会将$in操作拆分为两个单值查询（分别匹配field_1:"A"和field_1:"B"），每个子查询都能完整利用{field_1:1, field_2:1}的复合索引，快速定位对应分组中field_2>100的文档，最后合并结果。可以执行db.col.find(...).explain()查看执行计划，确认索引被使用（执行计划中会显示IXSCAN阶段）。

2. 两种查询方式是否存在性能差异？ #

存在明显性能差异。

• 原查询跳过了复合索引的前缀字段field_1，无法使用该索引，只能执行全表扫描（COLLSCAN）。当集合数据量较大时，全表扫描需要遍历所有文档，性能开销极高。
• 修改后的查询利用复合索引进行索引扫描（IXSCAN），直接定位符合条件的文档，无需遍历全集合，在数据量较大的场景下，性能远优于原查询。

3. 若第二种查询在部分场景有性能优势，是否存在性能更差的场景？ #

存在两种典型场景：

• 大部分文档满足field_2>100：此时修改后的查询需要扫描索引中field_1为"A"和"B"下的几乎全部field_2条目，再回表获取对应文档；而原查询的全表扫描无需额外的索引IO和回表操作，整体开销可能更低。
• 集合数据量极小：比如只有几十条文档时，全表扫描的本身开销就非常低，索引扫描带来的性能收益可以忽略，甚至因为索引的额外IO开销，修改后的查询性能会略差于原查询。

内容的提问来源于stack exchange，提问作者Bear Bile Farming is Torture