MongoDB v4中explain()未返回扫描文档数的问题及获取方法

一、为什么默认执行的explain()看不到扫描文档数？ #

从MongoDB 3.2版本开始，explain()方法拆分为三种运行模式，默认启用queryPlanner模式：

• 该模式仅返回查询优化器的计划选择逻辑，不会执行完整的真实查询流程，因此不会生成运行时的扫描数、耗时等执行统计数据——这就是你本地执行后只看到queryPlanner、serverInfo、ok三个顶级字段的原因。
• 《MongoDB in Action》成书时对应的MongoDB版本没有做模式区分，默认就会输出真实执行的全量统计结果，这也是旧示例中能直接看到nscanned、nscannedObjects字段的原因。

二、MongoDB v4 中如何获取扫描文档数等执行统计信息？ #

调用explain()时显式指定执行模式为executionStats即可，对应命令写法：

db.values.find({}).sort({close: -1}).limit(1).explain("executionStats")

该模式会在原有输出结构的基础上，新增一个executionStats顶级块，所有和旧版输出对应的执行统计字段都在这个块下，对应关系如下：

• 旧版nscannedObjects（扫描的文档总数） → 新版executionStats.totalDocsExamined，语义完全一致；以你当前的查询为例，由于执行计划是全表扫描（COLLSCAN）后接内存排序（SORT），该字段的数值就和书籍示例里的4308303这个全表扫描文档数完全对应
• 旧版nscanned（扫描的索引键总数） → 新版executionStats.totalKeysExamined，语义完全一致
• 旧版n（最终返回的文档数） → 新版executionStats.nReturned
• 旧版millis（查询执行总耗时） → 新版executionStats.executionTimeMillis
• 旧版scanAndOrder（是否发生内存排序） → 可通过查询计划判断：如果执行计划中存在独立的SORT阶段（而非直接从有序索引读取数据），即对应旧版scanAndOrder: true的场景；新版还会额外返回排序阶段溢出到磁盘的计数sortSpills，帮助判断内存排序的性能影响
• 如果需要获取所有候选查询计划的执行扫描数（对应旧版nscannedAllPlans、nscannedObjectsAllPlans字段），可以将模式替换为allPlansExecution，该模式会统计优化器评估所有候选计划时产生的扫描数据。

三、旧版explain的扫描数相关字段是被废弃了吗？ #

旧版的扫描数字段没有直接失效，而是随着explain输出结构的重构被调整、重命名了：

• 旧版explain是把所有查询计划、执行统计、服务器信息揉在一个扁平的顶级对象中，字段零散、语义边界模糊——比如旧版全表扫描场景下nscanned和nscannedObjects数值完全一致，很容易让使用者混淆统计维度。
• 新版输出按模块做了层级拆分，把计划选择、实际执行统计、节点信息分成独立的顶级块，所有统计字段的命名都做了语义优化来消除歧义：比如把容易混淆的nscanned拆成明确的「扫描索引键数」和「扫描文档数」两个独立字段；同时每个执行子阶段（比如COLLSCAN、IXSCAN、SORT）都会单独返回自己的扫描数，统计粒度比旧版更细。

内容的提问来源于stack exchange，提问作者Артем Поликарпов