MongoDB中使用$in运算符查询布尔值的性能影响问题

直接说结论：在逻辑等价于db.collection.find({})的场景下，两者性能几乎没有差异，可以从以下几个维度具体分析：

• 查询优化器的处理
  MongoDB的查询优化器会识别出{$in:[true,false]}针对布尔类型字段的匹配逻辑，当该字段所有有效值都是true/false时，优化器会将其执行计划优化为和全集合查询一致的路径——要么走全集合扫描，要么选择合适的索引（比如字段本身的索引或默认的_id索引），不会额外增加解析或执行成本。

• 索引的影响
  如果目标字段field上创建了索引，{$in:[true,false]}会遍历索引中所有标记为true和false的条目；而find({})如果使用索引的话，会遍历整个集合的索引（比如_id索引）。但因为布尔类型的索引基数极低（只有两个值），两种遍历的性能开销几乎可以忽略，不会有明显差异。如果没有创建任何索引，两者都会执行全集合扫描，性能完全一致。

• 特殊场景的差异
  只有当集合中存在field字段值非布尔类型（比如null、字符串），或者部分文档没有field字段时，两种查询的逻辑才会不一样——前者只会返回field为true/false的文档，后者返回所有文档。但你提到两者效果等同，说明你的场景不存在这种情况，所以无需考虑。

• 写法的合理性
  如果你用{$in:[true,false]}是为了明确过滤规则（比如防止后续业务中新增非布尔值的field数据干扰查询结果），这种写法反而更严谨，性能上的代价完全可以忽略，没必要刻意改成全集合查询。

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