为何MongoDB未为含$nin的特定查询选用复合索引？

文档结构 #

post = {"_id": "postID1", "userID": "userID1", "likeNum": 10, "url": "anyUrl"}

查询语句 #

posts_collection.find({"userID": {"$nin": ["uid1", "uid2"]}, "_id": {"$nin": ["postID1", "postID2"]}}).sort("likeNum", DESCENDING).limit(30).explain()

聚合管道 #

pipeline = [
    {"$match":{"userID": {"$nin": ["uid1", "uid2"]}, "_id": {"$nin": ["postID1", "postID2"]}}},
    {"$sort": {"likeNum": -1}},
    {"$group": {"_id": "$userID", "posts": {"$firstN": {"input": "$$ROOT", "n": 2}}}},
    {"$unwind": "$posts"},
    {"$replaceWith": "$posts"},
    {"$sort": {"likeNum": -1}},
    {"$limit": 30}
]
posts_collection.aggregate(pipeline)

索引配置 #

已创建两个索引：

• 单字段索引：likeNum: -1
• 复合索引：userID: 1, _id: 1, likeNum: -1

现象与疑问 #

explain()显示查询始终选用likeNum: -1索引并执行集合扫描，MongoDB Atlas查询分析器对聚合管道的分析结果也一致。想知道原因是$nin导致内存排序比集合扫描性能更差，还是其他因素？

备注：查询场景包括仅userID过滤、仅_id过滤、无过滤（这种情况用likeNum: -1索引可以理解），集合共10k条文档。

1. MongoDB选择likeNum: -1索引的核心原因 #

MongoDB查询优化器会评估不同索引的执行成本，选择成本最低的路径，这里选单字段索引而非复合索引，核心原因有三点：

• $nin的索引利用限制：复合索引userID:1, _id:1, likeNum:-1的前缀是userID和_id，但$nin属于否定类的非精确匹配，无法高效利用索引前缀做范围过滤。MongoDB需要遍历索引中所有不匹配的值，在10k文档的小数据集下，这种遍历成本反而高于直接用likeNum索引。
• sort+limit的优化逻辑：查询和聚合都需要按likeNum降序取前30条，likeNum: -1索引本身是预排序好的，MongoDB可以直接按顺序读取文档，同时校验$nin条件，直到凑够30条符合要求的数据。这种“边读边过滤”的方式，比先通过复合索引低效过滤、再排序的成本更低——毕竟复合索引过滤后无法直接利用后缀的likeNum排序优势，还需额外内存排序。
• 小数据集的成本评估：10k文档属于小集合，优化器会认为全索引扫描（用likeNum索引）加过滤的成本，比尝试用复合索引做低效过滤的成本更低，倾向选择更简单的执行路径。

2. 多场景索引优化建议 #

针对你提到的多种查询场景，调整索引策略如下：

• 仅userID过滤+按likeNum排序：创建复合索引userID:1, likeNum:-1，$match（包括$nin）可先按userID过滤，直接利用索引的likeNum排序，避免内存排序。
• 仅_id过滤+按likeNum排序：_id本身有默认单字段索引，若需结合排序，可创建复合索引_id:1, likeNum:-1，虽然_id的$nin过滤效率有限，但针对少量_id值的情况，仍能缩小扫描范围。
• 同时有userID和_id的$nin过滤+排序：若这类查询频繁，可尝试创建userID:1, _id:1, likeNum:-1或_id:1, userID:1, likeNum:-1，并用hint()强制指定复合索引测试性能——小数据集下优化器的成本评估可能有偏差，实际性能需实测验证。
• 聚合管道优化：管道中两次$sort存在冗余，$group前的$sort已经按likeNum降序，$firstN会按输入顺序取每个用户的前2条热门帖子，$unwind后无需再次排序，可删除最后一次$sort减少计算成本。

3. 关于内存排序的误区 #

你提到的“$nin的内存排序比集合扫描性能更差”并不准确。MongoDB选择likeNum索引恰恰是为了避免内存排序——因为该索引已预排序，直接读取即可；而若用复合索引，过滤后的文档大概率需要内存重新排序（无法利用索引后缀的排序优势）。优化器选单字段索引的核心是利用预排序减少内存开销，结合小数据集的过滤成本评估做出的选择。

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