MongoDB执行计划疑问：Sort阶段数据量远超Fetch及内存溢出问题

为什么Sort阶段works远大于Fetch返回的记录数？ #

从执行计划可拆解出MongoDB的执行逻辑：

1. 索引扫描阶段：查询使用expires_date单字段索引，IXSCAN先扫描出721379条符合expires_date范围条件的记录——这一步仅做索引层面筛选，未应用其他过滤规则。
2. 文档获取与过滤阶段：FETCH取出这721379条记录的完整文档，再逐一校验剩余过滤条件（state: "Active"、last_checked的$or规则等），最终仅保留3006条符合所有要求的记录。
3. works字段的含义：Sort阶段的works统计的是该阶段执行的所有工作单元数，包含初始化、接收上游输入、排序计算、清理等操作步骤，并非实际参与排序的记录数。实际参与排序的是Fetch筛选后的3006条记录，但这些记录的总大小超过了MongoDB默认的32MB排序内存限制，因此触发了内存溢出错误。

内存溢出错误的根源 #

由于未创建包含排序字段last_checked的复合索引，MongoDB无法利用索引直接完成排序，只能将所有待排序记录加载到内存中操作。当记录总大小超过默认的32MB内存阈值时，就会抛出Sort operation used more than the maximum 33554432 bytes of RAM错误。

• 优化方案1：创建复合索引（推荐）
  构建包含过滤条件和排序字段的复合索引，让MongoDB通过索引直接完成筛选与排序，彻底避免内存排序：

  db.mycollection.createIndex({ state: 1, expires_date: 1, last_checked: 1 })
  

  该索引会先按state筛选，再按expires_date范围过滤，最后直接按last_checked有序返回结果，全程无需内存排序操作。

• 优化方案2：应用端排序
  先执行查询获取所有符合条件的记录，再在应用端完成排序逻辑：

  // MongoDB仅做筛选，不执行排序
  const docs = db.mycollection.find({ 
    state: "Active", 
    expires_date: { $gte: new Date(1451586600000), $lte: new Date(1666003832377) }, 
    $or: [ { last_checked: { $lte: new Date(1658267660509) } }, { last_checked: { $exists: false } } ]
    // 其他过滤条件
  }).toArray();
  
  // 应用端按last_checked升序排序
  docs.sort((a, b) => a.last_checked - b.last_checked);
  

  这种方式将排序压力转移到应用端，规避MongoDB的内存限制问题。

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