MongoDB中$nin数组最大元素数阈值及与$lookup的性能切换点

核心结论 #

没有绝对固定的阈值，但实践中通常以200-500个元素作为分界点：当blockedUsers数组元素数低于这个范围时，$nin查询足够高效；超过这个范围后，改用$lookup的聚合查询性能会更优。

为什么会有这个分界？ #

• $nin的性能瓶颈：$nin本质是逐个比对数组内的元素，当数组变大时，MongoDB无法高效利用_id索引（即使有索引，也会因为需要遍历大量元素而导致索引扫描成本飙升），最终可能退化为全表扫描，查询耗时呈线性增长。
• $lookup的优势：当屏蔽列表较大时，$lookup通过关联查询（配合索引）过滤屏蔽用户，避免了$nin的数组遍历开销，尤其是在处理数百个以上的屏蔽ID时，聚合管道的执行效率会显著高于$nin。

影响阈值的变量 #

这个分界点不是固定值，会受以下因素影响：

• 集合总数据量：用户集合越大，$nin的性能下降越明显，阈值可能更低
• 硬件配置：CPU、内存、磁盘IO性能会影响两种查询的执行速度
• 索引情况：确保_id字段有默认索引，$lookup的关联字段也需有索引支撑

怎么验证自己的阈值？ #

1. 用explain("executionStats")分析两种查询的执行计划，重点看totalDocsExamined（扫描文档数）和executionTimeMillis（执行时间）
2. 针对你的业务数据，分别测试blockedUsers数组长度为100、300、500、1000时的查询耗时，找到适合自己的临界点

$lookup实现示例 #

如果改用聚合查询过滤屏蔽用户，示例代码如下：

// 直接传入屏蔽列表的聚合写法
const suggested_content = await db.collection('users').aggregate([
  {
    $match: {
      $expr: { $not: { $in: ['$_id', blockedUsers] } }
    }
  }
]).toArray();

// 屏蔽列表存在用户文档中的关联写法
const suggested_content = await db.collection('users').aggregate([
  // 获取当前用户的屏蔽列表
  { $match: { _id: currentUserId } },
  // 关联过滤非屏蔽用户
  {
    $lookup: {
      from: 'users',
      let: { blockedIds: '$blockedUsers' },
      pipeline: [
        {
          $match: {
            $expr: { $not: { $in: ['$_id', '$$blockedIds'] } }
          }
        }
      ],
      as: 'suggested_content'
    }
  },
  // 提取结果
  { $unwind: '$suggested_content' },
  { $replaceRoot: { newRoot: '$suggested_content' } }
]).toArray();

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