MongoDB $nin查询超时问题优化咨询

针对你500万条文档的集合，执行db.myCollection.find({team: {$nin: ['b']}}).sort({since: -1})超时的问题，结合现有索引情况，给出以下可行方案：

1. 调整复合索引结构 #

当前的[since, team]复合索引无法高效支撑你的查询逻辑——因为查询条件是针对非前缀字段team的$nin操作，而排序依赖前缀字段since，MongoDB无法充分利用索引的排序能力，大概率会触发全索引扫描甚至内存排序。

建议将索引改为{team: 1, since: -1}：

• 这个索引可以先通过team字段快速筛选出不包含'b'的文档，然后直接利用since的降序排序索引完成排序，完全避免额外的排序开销。
• 创建索引命令：db.myCollection.createIndex({team: 1, since: -1})
• 用db.myCollection.find({team: {$nin: ['b']}}).sort({since: -1}).explain("executionStats")验证，确认executionStats.totalDocsExamined远小于500万，且executionStats.executionStages.sortStage不存在（说明用了索引排序）。

2. 替换$nin为$in（如果业务允许） #

如果team的可选值是有限且已知的（比如只有a、b、c），直接用$in指定需要保留的取值，比$nin的查询效率更高：

db.myCollection.find({team: {$in: ['a', 'c']}}).sort({since: -1})

这种写法能更好地利用索引，尤其是当目标文档量远小于排除文档量时，性能提升会很明显。

3. 增加时间范围过滤 #

如果业务逻辑允许，给查询加上since的范围条件，大幅减少需要处理的数据量：

db.myCollection.find({
  team: {$nin: ['b']},
  since: {$gte: 1660000000} // 替换为业务需要的起始时间戳
}).sort({since: -1})

结合原有的[since, team]索引，MongoDB会先筛选出时间范围内的文档，再过滤team字段，处理的数据量大幅降低，超时问题自然缓解。

4. 使用投影减少数据传输 #

如果查询不需要返回完整文档，只提取必要字段（比如since和team），用投影功能减少网络传输的数据量，同时如果搭配覆盖索引（比如调整后的{team:1, since:-1}），还能实现从索引直接返回结果，无需回表查询：

db.myCollection.find(
  {team: {$nin: ['b']}},
  {since: 1, team: 1, _id: 0} // 只返回需要的字段
).sort({since: -1})

5. 临时调整超时参数（治标方案） #

如果上述优化暂时无法实施，可以临时延长查询超时时间，但这只是缓解手段，不能解决根本问题：

db.myCollection.find({team: {$nin: ['b']}}).sort({since: -1}).maxTimeMS(60000) // 设置60秒超时

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