MongoDB如何跨users、chat集合查询获取带未读消息计数的用户列表

直接在users集合上通过聚合管道完成跨集合关联与计数，无需在应用层做循环查询，从根源上避免N+1查询的性能损耗。

核心聚合逻辑 #

• 基于带自定义管道的$lookup操作关联chat集合，在数据库端完成未读消息的筛选与计数，不将全量匹配的消息拉取到内存计算
• 关联时传入动态参数：当前在线用户的ID（即active_user）作为固定接收方匹配值，当前遍历的用户ID作为发送方匹配值
• 在$project阶段按要求裁剪字段，对未读计数做默认值兜底，无匹配未读消息时count返回0

可直接运行的查询代码 #

// 替换为当前在线用户devanggarach对应的users集合_id值
const activeUserId = ObjectId("你的devanggarach用户ID")

db.users.aggregate([
  {
    $lookup: {
      from: "chat",
      let: { currentUserId: "$_id" },
      pipeline: [
        {
          $match: {
            $expr: {
              $and: [
                // 匹配发送方为当前遍历用户的消息
                { $eq: ["$sender_id", "$$currentUserId"] },
                // 匹配接收方为当前在线用户的消息
                { $eq: ["$receiver_id", activeUserId] },
                // 匹配未读状态的消息
                { $eq: ["$isRead", false] }
              ]
            }
          }
        },
        // 数据库端直接统计符合条件的消息数量，不返回原始消息内容
        { $count: "count" }
      ],
      as: "unreadStat"
    }
  },
  {
    $project: {
      _id: 1,
      username: 1,
      fname: 1,
      lname: 1,
      isOnline: 1,
      updatedAt: 1,
      // 无匹配未读消息时，count默认取0，避免返回null
      count: { $ifNull: [{ $first: "$unreadStat.count" }, 0] }
    }
  }
])

性能优化与注意事项 #

• 必须在chat集合上创建复合索引：{ sender_id: 1, receiver_id: 1, isRead: 1 }，让lookup阶段的匹配逻辑直接走索引，避免全表扫描
• 如果业务只需要展示和当前在线用户有过聊天交互的用户，可在$project阶段后追加{ $match: { count: { $gt: 0 } } }过滤无交互的条目
• 不要使用基础版的无管道$lookup拉取全量关联消息后在内存计算count，消息量较大时会造成内存溢出、查询延迟陡增

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