基于未修改字段排序时，MongoDB会使用对应索引吗？

结论 #

MongoDB 不会自动在你当前的管道结构中使用distance字段的索引进行排序。

原因分析 #

聚合管道按阶段顺序执行，你的管道里有几个环节会导致索引排序无法生效：

1. 文档结构变更：$set阶段会生成全新的文档对象，哪怕distance字段值没改，MongoDB的查询优化器不会默认处理后的文档和原集合文档保持索引可关联的映射关系。
2. 文档过滤操作：function_to_lookup_and_remove_blocked_users()里的$lookup及后续移除逻辑会过滤掉部分文档，改变了原集合的文档范围，优化器没法提前确定哪些文档能留存到排序阶段。
3. 排序阶段位置靠后：排序发生在$project之后，此时的文档是管道内的中间结果，原集合的索引无法直接作用于这些经过多阶段处理的文档。

优化方案 #

根据你的业务需求，可以通过调整管道顺序或重构过滤逻辑来利用索引排序：

方案1：提前排序+候选池过滤

先利用索引对全量用户按distance排序，取足够多的候选文档，再做后续的字段修改和封禁过滤，最后截取前50个结果。这种方式能大幅减少后续阶段处理的数据量：

db.user.aggregate([
  { $match: {} },
  { $sort: { distance: -1 } },
  { $limit: 100 }, // 候选池数量可根据封禁用户占比调整
  { $set: { name: "$last_name" } },
  ...function_to_lookup_and_remove_blocked_users(),
  { $project: { _id: 0, name: 1, distance: 1 } },
  { $limit: 50 }, // 最终获取50个有效结果
]);

方案2：提前过滤封禁用户

如果封禁用户的判断逻辑能整合到$match阶段（无需$lookup后再过滤），就能在排序前精准筛选出有效用户，此时排序可以直接使用索引：

db.user.aggregate([
  {
    $match: {
      // 假设封禁用户ID存储在blocked_users集合的user_id字段中
      _id: { $nin: db.blocked_users.distinct("user_id") }
    }
  },
  { $sort: { distance: -1 } },
  { $limit: 50 },
  { $set: { name: "$last_name" } },
  { $project: { _id: 0, name: 1, distance: 1 } },
]);

验证索引是否生效 #

可以通过执行计划验证排序是否使用了索引：

db.user.aggregate([你的管道内容], { explain: "executionStats" })

在输出的执行计划中，若SORT阶段的inputStage为IXSCAN，说明索引已被使用；若为COLLSCAN后的内存排序，则未用到索引。

内容的提问来源于stack exchange，提问作者Bear Bile Farming is Torture