大规模MongoDB中$nin/$ne查询性能优化及数据结构选型咨询

首先，咱们得先搞清楚为啥你的反向查询（找未被某个worker处理的文档）性能拉胯：MongoDB的索引对$ne、$nin、$exists:false这类否定性操作的天然支持不好——当大部分文档都满足“未被处理”时，索引扫描几乎等同于全表扫描，数据量上去后肯定扛不住。结合你的业务限制（数百万数据、数百个worker、未知worker列表、worker只处理特定type文档），我给你几个针对性的优化方案：

1. 用复合索引+业务过滤条件缩小结果集 #

这是最立竿见影的办法。既然每个worker只处理特定type的文档，且只关心前置worker是否处理过，那咱们就把这些高选择性的条件和worker处理状态结合起来做复合索引。

举个例子：假设worker_1只处理type="x"的文档，且必须等worker_0处理完才会接手。那先创建复合索引：

db.your_collection.createIndex({ type: 1, "worker_history_object.worker_0": 1 })

然后查询未被worker_1处理的文档时，用这个条件：

{
  type: "x",
  "worker_history_object.worker_0": true,
  "worker_history_object.worker_1": { $exists: false }
}

这个思路的核心是先用type和前置worker的状态过滤出一个极小的结果集，再在这个子集里检查当前worker是否未处理。哪怕最后一步是全扫描子集，因为数据量已经被大幅压缩，性能会比之前的全表扫描好N倍。

2. 优先选择对象结构存储处理历史 #

对比数组和对象两种结构，worker_history_object在查询单个worker状态时更直接，而且单个字段的索引（比如{"worker_history_object.worker_1":1}）比数组索引的效率更高——尤其是当worker数量多、每个文档的处理历史不长时，对象结构的索引维护和查询开销都更小。

3. 用部分索引进一步优化特定worker的查询 #

MongoDB 4.4+支持的部分索引可以帮你把索引范围缩小到某个worker真正关心的文档上，大幅减少索引大小和扫描时间。

还是拿worker_1举例，创建只包含type="x"且worker_0已处理的文档的部分索引：

db.your_collection.createIndex(
  { "worker_history_object.worker_1": 1 },
  { partialFilterExpression: { type: "x", "worker_history_object.worker_0": true } }
)

当worker_1查询时，MongoDB会直接在这个小索引里找worker_1不存在的文档，性能会再上一个台阶。

4. 利用MongoDB Atlas的集群特性放大效果 #

既然你用的是Atlas集群，还有两个特性可以用上：

• 分片集群：按type字段分片，这样每个worker查询时只会访问对应type的分片，避免跨分片扫描大量数据。
• 只读副本集：把查询流量分流到副本集节点，减轻主节点的写入压力，同时提升查询的并发能力。

5. 永远别单独用否定查询 #

记住一个原则：绝对不要只用$ne、$nin或$exists:false作为查询条件。一定要搭配高选择性的过滤条件（比如type、前置worker状态、甚至文档创建时间）先把结果集砍到最小，再做否定判断。

最后验证查询计划 #

每次调整索引后，用explain("executionStats")看看查询的执行情况，确认是否命中了目标索引，以及扫描的文档数是否大幅减少。比如：

db.your_collection.find({
  type: "x",
  "worker_history_object.worker_0": true,
  "worker_history_object.worker_1": { $exists: false }
}).explain("executionStats")

重点看executionStats.totalDocsExamined这个数值，只要它远小于总文档数，就说明优化生效了。

内容的提问来源于stack exchange，提问作者René Koller