MongoDB查询全量_session._id嵌套字段速度慢优化方案

现有总大小约40GB、包含8000+文档的MongoDB集合，单文档结构如下：

{
 _id: ObjectId("..."),
 _session: {
    _id: ObjectId("...")
 },
data: { /* 大体积字段，占集合99%以上存储 */ }
}

业务需求为提取全量文档的_session._id字段值，当前Python侧执行如下查询耗时过长：

cursor = collection.find({}, projection={'_session._id': 1})

已在MongoDB Compass中创建对应字段索引，但无法确认查询是否命中索引，需可落地的优化方案实现_session._id的快速拉取。

直接在Compass内置MongoSH或MongoDB Shell中执行如下语句查看执行计划：

// 替换成你的实际集合名
db.your_collection_name.find(
  {}, 
  {'_session._id': 1}
).explain("executionStats")

重点核对返回结果的三个核心指标：

• 若executionStats.executionStage返回COLLSCAN，说明查询走全表扫描，完全没命中索引
• 若返回IXSCAN但executionStats.totalDocsExamined等于集合总文档数，说明命中了索引但发生了回表，没有实现覆盖查询，性能依然很差
• 只有当executionStats.executionStage为IXSCAN，且totalDocsExamined为0时，才是真正走了覆盖索引，不需要读取原文档数据。

核心优化：使用覆盖索引避免回表 #

覆盖索引是本次优化的核心，没有之一。8k文档本身数量极小，查询慢的核心原因是：如果不走覆盖索引，哪怕只需要_session._id一个字段，MongoDB也必须从磁盘读取每个文档完整的BSON内容（包括占绝大体积的data字段），40GB的磁盘IO开销是耗时过长的根本原因。覆盖索引可以让查询直接从索引树取数据，完全不碰存储大字段的集合数据文件，性能会提升数百倍。
根据业务需求二选一配置即可：

• 如果不需要返回根文档的_id字段（绝大多数拉取外键的场景都不需要）：
  1. 确认已经创建了{'_session._id': 1}的单字段升序索引
  2. 修改查询语句，显式排除根_id字段，让单字段索引直接成为覆盖索引：

  cursor = collection.find(
      {},
      # 显式排除_id，查询所需字段只剩_session._id，完全被单字段索引覆盖
      projection={'_session._id': 1, '_id': 0}
  )
  

• 如果业务必须同时返回根文档_id和_session._id：
  1. 创建联合覆盖索引，语句如下：

  db.your_collection_name.createIndex(
    {'_session._id': 1, '_id': 1},
    {name: 'idx_session_id_cover'}
  )
  

  2. 原有查询语句不需要调整，两个返回字段都在索引中，自动触发覆盖查询。

细节优化：调整Python游标参数减少网络开销 #

覆盖索引建好后，查询本身的IO开销已经极低，此时可以调整游标参数减少网络往返次数：

cursor = collection.find(
    {},
    projection={'_session._id': 1, '_id': 0}
# 设置单次拉取批次大小为2000，8k文档只需要4次网络请求即可拉完
).batch_size(2000)

# 直接迭代游标处理结果，不要一次性全量加载到内存（当前数据量小无影响，后续数据上涨可避免OOM）
session_ids = []
for doc in cursor:
    session_ids.append(doc['_session']['_id'])

• 不要在Compass的可视化界面直接执行全量查询验证性能，Compass的结果渲染、默认条数限制会干扰性能判断，直接用Python脚本或Shell执行验证即可。
• MongoDB 4.2及以上版本建索引默认不会阻塞线上读写，不需要额外加后台建索引参数。

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