如何优化MongoDB中大数组场景下的$in查询性能？

一、查询逻辑优化 #

• 避免全量拉取权限ID数组再做$in：当前逻辑是先把用户所有有权限的书籍ID全查出来再塞到$in里，当权限ID达到数千条以上时，$in的匹配开销、数据库查询计划开销都会陡增，同时大数组的跨网络传输也会产生额外的性能损耗。
• 优先用$lookup关联查询替代两次查询：直接在单次查询中完成权限校验和书籍查询，避免大数组在应用和数据库之间传输，参考代码：

db.user_access.aggregate([
  // 先匹配对应用户的权限记录
  {$match: {uid: "user1"}},
  // 关联books集合，直接匹配有权限的书籍
  {$lookup: {
    from: "books",
    localField: "books",
    foreignField: "_id",
    as: "accessible_books"
  }},
  // 展开结果做分页
  {$unwind: "$accessible_books"},
  {$replaceRoot: {newRoot: "$accessible_books"}},
  {$skip: 0},
  {$limit: 10}
])

• MongoDB 5.1+版本支持$lookup并行哈希关联，大数组场景下性能比旧版本提升数倍。

二、集合设计优化 #

• 权限字段反范式冗余到books集合：如果权限变更频率很低，可直接在books集合新增authorized_users数组字段，存储所有有权限查看本书的用户ID，查询时直接过滤该字段即可，完全避免$in或者关联操作，查询代码：

// 直接查询当前用户有权限的书籍，分页性能拉满
db.books.find({authorized_users: "user1"}).limit(10).skip(0)

• 分桶存储用户权限：如果单个用户的权限ID数量超过1万，可将user_access里的单条权限记录拆成多条分桶记录，每条存储固定数量的书籍ID，避免单条文档过大，同时也能提升关联查询性能。
• 避免用_id做权限匹配：如果书籍有固定长度的业务唯一字段（比如ISBN），用业务字段做关联比可变长度的ObjectId开销更低。

三、索引优化 #

• 给user_access集合的uid字段加唯一索引，保证查询用户权限的效率：db.user_access.createIndex({uid: 1}, {unique: true})
• 如果采用冗余authorized_users的方案，给该字段加多键索引：db.books.createIndex({authorized_users: 1})
• 若保留原有$in方案，books集合的_id默认是主键索引不需要额外创建，但$in数组长度超过1000时索引收益会明显下降，仍优先建议修改查询逻辑。

四、分页优化 #

• 禁用大偏移量skip：分页深度较高时，skip会跳过大量已匹配文档导致性能下降，改用基于上次查询最后一条_id的游标分页：

// 第一页查询后记录最后一条数据的_id为last_id
// 第二页直接用_id过滤，不需要skip
db.books.find({authorized_users: "user1", _id: {$gt: last_id}}).limit(10)

• 如果权限数组的ID本身是有序存储的，可以提前在应用层做分页，每次仅取当前页需要的10个ID做$in查询，完全避免大数组$in的开销，该方案性能最优：

// 例：第一页取权限数组的前10个ID查询
const page_book_ids = books.slice(0, 10)
db.books.find({_id: {$in: page_book_ids}})

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