MongoDB中维护多列表项位置：哪种模式性能更优？

我目前有lists和items两个集合，每个条目可归属任意数量的列表，且在每个列表中拥有自定义排序位置。下面针对两种建模方案做性能对比，同时给出优化建议：

方案A：条目文档内维护列表关联信息 #

在items集合的每个文档中，用数组存储所属列表及对应位置：

/* item schema */
{
  _id: ObjectID, // itemID
  lists: [
    {
      _id: ObjectID, // 所属列表ID
      orderNr: Number, // 在该列表中的位置
    }
  ]
}

优缺点分析 #

• 优势：无需额外集合，维护逻辑简单——条目加入/移出列表时，仅需更新当前item文档的lists数组。
• 劣势：列表维度的查询性能拉胯。假设要查询某列表的前N个条目，你需要：
  1. 用lists._id匹配目标列表（即使给lists._id建索引，也只能过滤出属于该列表的条目）；
  2. 从每个匹配的item文档中提取对应列表的orderNr；
  3. 对所有条目按orderNr排序后取前N条。
     当列表包含大量条目（比如数千条）时，排序操作会占用大量内存，且无法利用索引优化排序——因为orderNr是嵌套在数组中的，每个item的orderNr对应不同列表，无法建立全局的“列表ID+位置”复合索引。

方案B：新增contexts集合存储列表条目顺序 #

新增contexts集合，每个文档对应一个列表的条目排序信息：

/* context schema */
{
    _id: ObjectID,
    listID: ObjectID,
    items: [
        {
            _id: ObjectID, // itemID
            orderNr: Number // 在该列表中的位置
        }
    ]
}

优缺点分析 #

• 优势：列表维度查询效率极高。查询某列表的前N个条目时，只需：
  1. 通过listID精准定位到对应的context文档；
  2. 对文档内的items数组按orderNr排序，取出前N个itemID；
  3. 批量查询items集合获取条目详情。
     这个过程是精准查询单个文档，排序仅针对该列表的条目数组，性能开销极小。
• 劣势：维护成本略高。条目加入/移出列表、调整位置时，需要同步更新对应context文档；另外，如果列表条目数量极大（比如超过1万条），context文档可能会接近MongoDB的16MB文档大小限制。

关于方案A的性能疑问 #

你担心方案A需要遍历所有条目是对的，但实际如果给lists._id建索引，MongoDB会通过索引快速过滤出属于目标列表的条目，不会全表扫描。但核心问题是排序和分页的性能瓶颈——如前文所说，无法利用索引做“列表ID+位置”的排序，大数据量下排序开销会非常大。

第三种方案：独立关联集合（推荐） #

如果要兼顾维护简单和性能，建议采用**list_item关联集合**，每个文档存储一对列表-条目关联及位置：

/* list_item schema */
{
  _id: ObjectID,
  listID: ObjectID,
  itemID: ObjectID,
  orderNr: Number
}

优势 #

1. 查询高效：给listID和orderNr建立复合索引，查询某列表的前N个条目时，直接通过索引排序并取数，无需处理数组；
2. 维护灵活：条目加入/移出列表时，仅需增删list_item文档；调整位置时，修改对应文档的orderNr即可（若要插入中间位置，可通过使用浮点数或预留间隙来减少批量调整操作）；
3. 无大小限制：每个文档体积很小，不会出现方案B的文档大小超限问题。

总结 #

• 若列表条目数量少（几百条以内），且维护优先级高于性能，方案A可凑合用；
• 若列表条目数量中等，且查询频率高，方案B足够高效；
• 若列表条目数量大，或需要频繁做排序分页操作，独立关联集合的方案是最优选择。

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