/ /

/ /

解释结果

MongoDB提供了以下方法来返回查询计划信息和执行统计信息：

要学习；了解如何解释结果，请参阅解释解释计划结果。

重要

explain 忽略计划缓存。相反，系统会生成一组候选计划，并在不咨询计划缓存的情况下选择获胜者。此外，explain 会阻止 MongoDB 查询规划器缓存获胜计划。

注意

本文档介绍了最重要的输出字段。未记录供内部使用的字段。字段可能会发生变化。

解释输出结构

explain 结果将查询计划显示为阶段树。操作使用的是经典查询引擎还是基于槽的执行查询引擎，结构会有所不同：

winningPlan: {
   stage: <STAGE1>,
   ...
   inputStage: {
      stage: <STAGE2>,
      ...
      inputStage: {
         stage: <STAGE3>,
         ...
      }
   }
},

winningPlan: {
   queryPlan: {
      stage: <STAGE1>,
      ...
      inputStage: {
         stage: <STAGE2>,
         ...
         inputStage: {
            stage: <STAGE3>,
            ...
         }
      }
   }
   slotBasedPlan: {
      ...
   }
},

每个阶段都将其文档或索引键传递给父节点。叶节点访问权限集合或索引。内部节点使用子节点的输出。节点表示MongoDB最终派生出结果设立的阶段。

阶段名称描述了操作：

COLLSCAN 用于集合扫描
IXSCAN 用于扫描索引键
FETCH 用于检索文档
GROUP 用于对文档进行分组
SHARD_MERGE 用来合并来自分片的结果
SHARDING_FILTER 用于从分片中筛掉孤儿文档
TS_MODIFY 用于修改时间序列集合
BATCHED_DELETE 用于在内部批处理的多个文档删除（从 MongoDB 6.1 开始）
EOF 用于当阶段处于流结束时
EXPRESS 为一组有限的查询提供阶段，这些查询可以绕过常规查询计划，使用优化的索引扫描计划（版本 8.0 中的新功能。）
EXPRESS 阶段可以是以下之一：
- EXPRESS_CLUSTERED_IXSCAN
- EXPRESS_DELETE
- EXPRESS_IXSCAN
- EXPRESS_UPDATE

解释 MongoDB 5.1 和更高版本的输出

本部分显示 MongoDB 5.1 及更高版本的 explain 输出。要查看旧版本 MongoDB 的解释输出，请参阅该版本的文档。

explain.explainVersion

整型字段。

explainVersion 是该计划的输出格式版本，例如 "1" 或 "2"。

5.1 版本中的新功能。

`queryPlanner`

explain.queryPlanner 详细说明了查询优化器选择的计划。

以下示例可能会结合经典执行引擎和基于插槽的执行引擎的输出，因此不具有代表性。您的输出可能会有所不同。

对于未分片的集合，explain 将返回以下 queryPlanner 信息：

queryPlanner: {
   namespace: <string>,
   indexFilterSet: <boolean>,
   parsedQuery: {
      ...
   },
   planCacheShapeHash: <hexadecimal string>,
   planCacheKey: <hexadecimal string>,
   maxIndexedOrSolutionsReached: <boolean>,
   maxIndexedAndSolutionsReached: <boolean>,
   maxScansToExplodeReached: <boolean>,
   winningPlan: {
     stage: <STAGE1>,
     type: <string>,
     inputStage: {
       stage: <string>,
       ...
     }
   },
   rejectedPlans: [
     <candidate plan1>,
   ]
}

从MongoDB 8.0 开始，现有的 queryHash字段将复制到名为 planCacheShapeHash 的新字段中。如果您使用的是早期MongoDB版本，则只能看到 queryHash字段。未来的MongoDB版本将删除已弃用的 queryHash字段，您需要改用 planCacheShapeHash字段。

对于分片集合，explain 包括核心查询规划器和 shards 字段中每个被访问分片的服务器信息：

{
   queryPlanner: {
      mongosPlannerVersion: <int>
      winningPlan: {
         stage: <STAGE1>,
         type: <string>,
         shards: [
         {
            shardName: <string>,
            connectionString: <string>,
            serverInfo: {
               ...
            },
            namespace: <string>,
            indexFilterSet: <boolean>,
            parsedQuery: {
               ...
            },
            querySettings: {
               ...
            },
            planCacheShapeHash: <hexadecimal string>,
            planCacheKey: <hexadecimal string>,
            maxIndexedOrSolutionsReached: <boolean>,
            maxIndexedAndSolutionsReached: <boolean>,
            maxScansToExplodeReached: <boolean>,
            winningPlan: {
               stage: <STAGE1>,
               type: <string>,
               inputStage: {
                  stage: <string>,
                  ...
               }
            },
            rejectedPlans: [
              <candidate plan1>,
            ]
         }
         ]
      }
   }
}

explain.queryPlanner

包含有关查询优化器选择的查询计划的信息。

explain.queryPlanner.namespace: 以命名空间格式 <database>.<collection> 指定查询访问的数据库和集合的字符串。

explain.queryPlanner.indexFilterSet: 一个布尔值，用于指定 MongoDB 是否对计划缓存查询结构应用索引过滤器。

explain.queryPlanner.querySettings

如果设置了查询设置，则 querySettings 包含有关应用于查询结构的查询设置的详细信息。

要添加查询设置并浏览示例（其中包括 explain() 输出和 querySettings），请参阅 setQuerySettings。

8.0版本新增。

explain.queryPlanner.planCacheShapeHash

十六进制字符串.计划缓存查询结构的哈希，仅依赖于计划缓存查询结构。使用它来查找具有相同计划缓存查询结构的慢速查询。

注意

不同计划缓存查询结构之间可能会发生哈希冲突，但可能性很小。

有关 planCacheShapeHash 和 planCacheKey 的更多信息，请参阅 planCacheShapeHash 和 planCacheKey。

explain.queryPlanner.planCacheKey

计划缓存条目键的哈希值。与 explain.queryPlanner.planCacheShapeHash 不同，此值是查询结构和当前可用索引的函数。添加或删除支持索引可能会更改 planCacheKey，但不会更改 planCacheShapeHash。

有关 planCacheShapeHash 和 planCacheKey 的更多信息，请参阅 planCacheShapeHash 和 planCacheKey。

explain.queryPlanner.optimizationTimeMillis: 用于查询优化的毫秒数。不包括优化内部 $lookup 查询的时间。

explain.queryPlanner.optimizedPipeline

一个布尔值，表明整个聚合管道操作已被优化掉，改用查询计划执行阶段树来实现。

例如，以下聚合操作可以通过查询计划执行树来完成，而不使用聚合管道。

db.example.aggregate([ { $match: { someFlag: true } } ] )

仅当值为 true 时，该字段才存在，并且仅适用于解释聚合管道操作。为 true 时，由于管道已被优化掉，所以输出中不会出现聚合阶段信息。

explain.queryPlanner.winningPlan: 查询优化器选择的计划的文档。

explain.queryPlanner.winningPlan.stage

指示阶段名称的字符串。每个阶段都包含特定于其类型的信息（示例，IXSCAN 包括索引边界）。具有子阶段的阶段具有 inputStage 或 inputStages字段。

当操作使用经典查询执行引擎时存在。

explain.queryPlanner.winningPlan.type

如果将 stage设立为 "EOF"，则 type 是一个字符串，表示 EOF 阶段的原因：

"nonExistentNamespace"：查询命名空间不存在。
"predicateEvalsToFalse"：表达式简化确定查询与任何文档都不匹配。

explain.queryPlanner.winningPlan.inputStage: 描述向其父阶段提供文档或索引键的子阶段的文档。当父项只有一个子项时出现。

explain.queryPlanner.winningPlan.inputStages

描述子阶段的文档数组。子阶段为父阶段提供文档或索引键。当父节点有多个子节点时出现，例如在$or表达式中。

当操作使用经典查询执行引擎时存在。

explain.queryPlanner.winningPlan.isCached

一个布尔值，用于指示赢得计划是否在计划缓存中。

最多有一个计划（获胜或被拒绝）将此字段设立为 true。如果不存在缓存的计划，则所有计划的该字段都为 false。

explain.queryPlanner.winningPlan.queryPlan

包含查询优化器选择的计划的文档，以阶段树的形式呈现。

查询使用基于插槽的执行查询引擎时出现。

5.1 版本中的新功能。

explain.queryPlanner.winningPlan.queryPlan.stage

指示阶段名称的字符串。

每个阶段都包含特定于其类型的信息。示例，IXSCAN 包括索引边界。

explain.queryPlanner.winningPlan.queryPlan.type

如果将 stage设立为 "EOF"，则 type 是一个字符串，表示 EOF 阶段的原因：

"nonExistentNamespace"：表示查询命名空间不存在。
"predicateEvalsToFalse"：表示表达式简化确定该查询不会匹配任何文档。

explain.queryPlanner.winningPlan.queryPlan.planNodeId: 标识执行计划中每个阶段的唯一整型字段。字段包含在整个 explain 结果的所有阶段中。
5.1 版本中的新功能。

explain.queryPlanner.winningPlan.queryPlan.inputStage: 请参阅 explain.queryPlanner.winningPlan.inputStage。

explain.queryPlanner.winningPlan.slotBasedPlan: 一份文档，包含有关基于槽位的查询执行计划树和阶段的信息。供 MongoDB 内部使用。
5.1 版本中的新功能。

explain.queryPlanner.winningPlan.slotBasedPlan.stages

包含基于插槽的查询执行计划中每个阶段的信息的字符串，包括执行顺序、操作和插槽分配。供 MongoDB 内部使用。

从 MongoDB 8.0开始，如果查询使用块处理，则 block_to_row 和 ts_bucket_to_cellblock 会出现在 stages 输出中。

在版本8.0中进行了更改。

explain.queryPlanner.rejectedPlans

查询优化器考虑和拒绝的候选计划数组。如果没有其他候选计划，则数组可能为空。

被拒绝的计划具有与explain.queryPlanner.winningPlan相同的字段。

从 MongoDB 8.0 开始，被拒绝的查询计划只包含查询的 find 部分。在以前的版本中，被拒绝的计划可以包含聚合阶段，例如 $group。查询规划器不使用这些聚合阶段来选择获胜计划，因此 rejectedPlans 字段只包含查询中用于选择获胜计划的部分。

`executionStats`

返回的 explain.executionStats 信息详细说明了获胜计划的执行情况。为了在结果中包含 executionStats，您必须在如下位置运行解释：

executionStats 或
allPlansExecution 冗余模式。使用 allPlansExecution 模式以包含计划选择过程中捕获的部分执行数据。

这些示例可能结合了 MongoDB 的经典执行引擎和基于槽位的执行引擎的输出结构。它们并不具有代表性。您的输出可能与之有巨大差异。

对于未分片的集合，explain 将返回以下 executionStats 信息：

executionStats: {
   executionSuccess: <boolean>,
   nReturned: <int>,
   executionTimeMillis: <int>,
   totalKeysExamined: <int>,
   totalDocsExamined: <int>,
   executionStages: {
      stage: <STAGE1>
      nReturned: <int>,
      executionTimeMillisEstimate: <int>,
      opens: <int>, // Starting in MongoDB 5.1
      closes: <int>, // Starting in MongoDB 5.1
      works: <int>,
      advanced: <int>,
      needTime: <int>,
      needYield: <int>,
      saveState: <int>,
      restoreState: <int>,
      isEOF: <boolean>,
      ...
      inputStage: {
         stage: <STAGE2>,
         nReturned: <int>,
         ...
         numReads: <int>, // Starting in MongoDB 5.1
         ...
         executionTimeMillisEstimate: <int>,
         ...
         spills: <long long>,
         spilledBytes: <long long>,
         spilledRecords: <long long>,
         spilledDataStorageSize: <long long>,
         ...
         inputStage: {
            ...
         }
      }
   },
   allPlansExecution: [
      {
         nReturned: <int>,
         executionTimeMillisEstimate: <int>,
         totalKeysExamined: <int>,
         totalDocsExamined: <int>,
         score: <double>,
         executionStages: {
            stage: <STAGEA>,
            nReturned: <int>,
            executionTimeMillisEstimate: <int>,
            ...
            inputStage: {
               stage: <STAGEB>,
               ...
               inputStage: {
                 ...
               }
            }
         }
      },
      ...
   ]
   operationMetrics: {
      cpuNanos: <int>,
      cursorSeeks: <int>,
      docBytesRead: <int>,
      docBytesWritten: <int>,
      docUnitsRead: <int>,
      docUnitsReturned: <int>,
      docUnitsWritten: <int>,
      idxEntryBytesRead: <int>,
      idxEntryBytesWritten: <int>,
      idxEntryUnitsRead: <int>,
      idxEntryUnitsWritten: <int>,
      totalUnitsWritten: <int>,
      keysSorted: <int>,
      sorterSpills: <int>
   }
}

对于分片集合，explain 包括每个访问的分片的执行统计信息。

executionStats: {
   nReturned: <int>,
   executionTimeMillis: <int>,
   totalKeysExamined: <int>,
   totalDocsExamined: <int>,
   executionStages: {
      stage: <STAGE1>
      nReturned: <int>,
      executionTimeMillis: <int>,
      opens: <int>, // Starting in MongoDB 5.1
      closes: <int>, // Starting in MongoDB 5.1
      totalKeysExamined: <int>,
      totalDocsExamined: <int>,
      totalChildMillis: <NumberLong>,
      shards: [
         {
            shardName: <string>,
            executionSuccess: <boolean>,
            executionStages: {
               stage: <STAGE2>,
               nReturned: <int>,
               executionTimeMillisEstimate: <int>,
               ...
               chunkSkips: <int>,
               inputStage: {
                  stage: <STAGE3>,
                  ...
                  numReads: <int>, // Starting in MongoDB 5.1
                  ...
                  spills: <long long>,
                  spilledBytes: <long long>,
                  spilledRecords: <long long>,
                  spilledDataStorageSize: <long long>,
                  ...
                  inputStage: {
                     ...
                  }
               }
            }
         },
         ...
      ]
   }
   allPlansExecution: [
      {
         shardName: <string>,
         allPlans: [
            {
               nReturned: <int>,
               executionTimeMillisEstimate: <int>,
               totalKeysExamined: <int>,
               totalDocsExamined:<int>,
               executionStages: {
                  stage: <STAGEA>,
                  nReturned: <int>,
                  executionTimeMillisEstimate: <int>,
                  ...
                  inputStage: {
                     stage: <STAGEB>,
                     ...
                     inputStage: {
                       ...
                     }
                  }
               }
            },
            ...
         ]
      },
      {
         shardName: <string>,
         allPlans: [
          ...
         ]
      },
      ...
   ]
}

explain.executionStats

包含描述入选计划的已完成查询执行的统计信息。对于写入操作，已完成的查询执行是指将要执行的修改，但不将这些修改应用到数据库。

explain.executionStats.nReturned: 获胜查询计划返回的文档数。nReturned 对应于早期版本的 MongoDB 中的 cursor.explain() 返回的 n 字段。

explain.executionStats.executionTimeMillis

选择查询计划和执行查询所需的总时间（以毫秒为单位）。它包括运行计划选择过程的试用阶段部分所需的时间，但不包括将数据传输回客户端的网络时间。

explain.executionStats.executionTimeMillis 报告的时间不一定代表实际查询时间。在稳定状态操作期间（缓存查询计划时），或者将 cursor.hint() 与 cursor.explain() 一起使用时，MongoDB 会绕过计划选择过程，从而缩短实际时间，从而导致 explain.executionStats.executionTimeMillis 值更低。

explain.executionStats.totalKeysExamined: 扫描的索引项数。explain.executionStats.totalKeysExamined 对应于早期版本的 MongoDB 中的 cursor.explain() 返回的 nscanned 字段。

explain.executionStats.totalDocsExamined: 查询执行过程中检查的文档数量。检查文档的常见查询执行阶段是 COLLSCAN 和 FETCH。
注意
explain.executionStats.totalDocsExamined 是指已检查的文档总数，而非返回的文档数量。例如，阶段可以按照顺序检查文档以应用过滤器。如果文档被过滤掉，则说明它已被检查过，但不会纳入查询结果集返回。
如果在查询执行过程中多次检查了一个文档，explain.executionStats.totalDocsExamined 会对每次检查进行计数。也就是说，explain.executionStats.totalDocsExamined 不是所检查的唯一文档的总数。

explain.executionStats.executionStages

以阶段树的形式详细说明获胜计划的执行情况；即一个阶段可以有一个 inputStage 或多个 inputStages。

从 MongoDB 5.1 开始，一个阶段可以具有以下输入阶段：

thenStage
elseStage
innerStage
outerStage

每个阶段都包含针对该阶段的执行信息。

explain.executionStats.executionStages.executionTimeMillisEstimate: 查询执行的估计时间（以毫秒为单位）。

explain.executionStats.executionStages.opens: 从 MongoDB 5.1 开始，查询执行期间打开阶段的次数。

explain.executionStats.executionStages.closes: 从 MongoDB 5.1 开始，查询执行期间阶段关闭的次数。

explain.executionStats.executionStages.works

指定查询执行阶段执行的“工作单元”数量。查询执行将其工作划分为多个小单元。“工作单元”可能包括检查单个索引键、从集合中获取单个文档、将投影应用于单个文档或进行内部簿记。

如果该操作使用经典查询执行引擎，则会显示此字段。

explain.executionStats.executionStages.saveState: 查询阶段暂停处理并保存其当前执行状态的次数，例如在准备放弃其锁时。

explain.executionStats.executionStages.restoreState: 查询阶段恢复了已保存的执行状态的次数，例如在恢复此前生成的锁之后。

explain.executionStats.executionStages.isEOF

指定执行阶段是否已到达流结束：

如果为 true 或 1，则执行阶段已到达流结束。
如果为 false 或 0，则该阶段可能仍有结果要返回。考虑一个具有限制的查询，其执行阶段由 LIMIT 个阶段组成，输入阶段为 IXSCAN。如果查询返回的结果超过指定的限制，则 LIMIT 阶段将报告 isEOF: 1，但其底层的 IXSCAN 阶段将报告 isEOF: 0。

explain.executionStats.executionStages.opType: 对于时间序列集合上的操作，为操作类型。

explain.executionStats.executionStages.bucketFilter: 对于时间序列集合上的操作，为用于减少在存储桶目录中查询的存储桶数量的过滤器。

explain.executionStats.executionStages.residualFilter: 对于时间序列集合上的操作，为用于查询存储桶目录的过滤器。

explain.executionStats.executionStages.nBucketsUnpacked: 对于时间序列集合上的操作，是为解决操作而解压缩的存储桶数。

explain.executionStats.executionStages.nMeasurementsDeleted: 对于时间序列集合上的操作，为删除的文档数。

explain.executionStats.executionStages.nMeasurementsInserted: 对于时间序列集合上的操作，插入的文档数量。

explain.executionStats.executionStages.nMeasurementsMatched: 对于时间序列集合上的操作，匹配的文档数量。

explain.executionStats.executionStages.nMeasurementsModified: 对于时间序列集合上的操作，为修改的文档数。

explain.executionStats.executionStages.nMeasurementsUpserted: 对于时间序列集合上的操作，为所更新插入的文档数量。

explain.executionStats.executionStages.inputStage

每个 inputStage 可以有不同的字段，具体取决于 inputStage.stage 的值。下表描述了可能的字段以及它们可以出现在哪些阶段。

每个 inputStage 可以具有另一个 inputStage 作为字段。请参阅解释输出结构。

字段	说明	适用阶段
`docsExamined`	指定在查询执行阶段扫描的文档数量。	`COLLSCAN`, `FETCH`
`keysExamined`	对于扫描索引的查询执行阶段，`keysExamined` 是在索引扫描过程中检查的界内和界外键的总数。如果索引扫描由单个连续范围的键组成，则仅需要检查界内键。如果索引边界由多个键范围组成，则索引扫描执行过程可能会检查界外键，以便从一个范围的末尾跳到下一个范围的开头。	`IXSCAN`
`numReads`	在查询执行阶段扫描的文档或检查的索引键的数量。 5.1 版本中的新功能。	`COLLSCAN`, `IXSCAN`
`seeks`	为了完成索引扫描而必须让索引游标搜索新位置的次数。	`IXSCAN`
`usedDisk`	该阶段是否已写入磁盘。 5.3 版本中的新增功能。	`GROUP`
`spills`	该阶段溢出到磁盘的次数。 8.2版本新增。	`GROUP`, `SORT`
`spilledBytes`	写入磁盘的数据总量（以字节为单位）。 8.2版本新增。	`GROUP`, `SORT`
`spilledRecords`	溢出到磁盘的单条记录总数。 8.2版本新增。	`GROUP`, `SORT`
`spilledDataStorageSize`	溢出数据使用的总磁盘空间（以字节为单位）。 8.2版本新增。	`GROUP`, `SORT`

explain.executionStats.allPlansExecution: 包含在计划选择阶段为中标和被拒计划捕获的部分执行信息。该字段仅在 explain 以 allPlansExecution 详细模式运行时出现。

explain.executionStats.operationMetrics: 包含资源消耗统计信息，只要它们不为零。仅当 explain 在 executionStats 详细模式或更高模式下运行并且 profileOperationResourceConsumptionMetrics 已启用时，该字段才会出现。
警告
MongoDB 8.2 删除 profileOperationResourceConsumptionMetrics。因此，依赖于operationMetrics的代码不起作用。

`serverInfo`

对于未分片集合， explain 返回 MongoDB 实例的以下 serverInfo 信息：

serverInfo: {
   host: <string>,
   port: <int>,
   version: <string>,
   gitVersion: <string>
}

对于分片集合， explain 返回每个所访问分片的 serverInfo，并返回 mongos 的顶级 serverInfo 对象。

queryPlanner: {
   ...
   winningPlan: {
      stage: <STAGE1>,
      shards: [
         {
            shardName: <string>,
            connectionString: <string>,
            serverInfo: {
               host: <string>,
               port: <int>,
               version: <string>,
               gitVersion: <string>
            },
            ...
         }
         ...
      ]
   }
 },
 serverInfo: {      // serverInfo for mongos
   host: <string>,
   port: <int>,
   version: <string>,
   gitVersion: <string>
 }
 ...

具有 `$lookup` 管道阶段的查询的执行计划统计信息

版本 5.0 中的新增功能。

解释结果可包括使用 $lookup 管道阶段的查询的执行统计数据。要包含这些执行统计信息，您必须在以下执行详细模式运行解释操作：

以下字段包含在 $lookup 查询的解释结果中：

'$lookup': {
   from: <string>,
   as: <string>,
   localField: <string>,
   foreignField: <string>
},
totalDocsExamined: <long>,
totalKeysExamined: <long>,
collectionScans: <long>,
indexesUsed: [ <string_1>, <string_2>, ..., <string_n> ],
executionTimeMillisEstimate: <long>

要查看 $lookup 部分中字段的说明，请参阅 $lookup 页面。

其他字段为：

explain.totalDocsExamined: 查询执行过程中检查的文档数量。

explain.totalKeysExamined: 检查的索引键的数量。

explain.collectionScans: 在查询执行期间发生集合扫描的次数。在集合扫描期间，集合中的每个文档都会与查询谓词进行比较。如果不存在涵盖此查询的相应索引，则会进行集合扫描。

explain.indexesUsed: 包含查询所用索引名称的字符串的数组。

explain.executionTimeMillisEstimate: 查询执行的估计时间（以毫秒为单位）。

搜索查询的执行计划统计信息

8.1版本新增。

解释结果包括使用 $search、$searchMeta 或$vectorSearch 管道阶段的查询的执行统计信息。要包含搜索查询的执行统计信息，请在以下执行详细模式之一运行explain 命令：

MongoDB返回仅使用经典引擎的搜索和向量搜索查询的执行统计信息。

有关搜索和向量搜索查询解释结果的更多详细信息，请参阅：

集合扫描(collection scan)

如果查询规划器选择集合扫描，解释结果将包含 COLLSCAN 阶段。

如果查询规划器选择索引，解释结果将包含 IXSCAN 阶段。该阶段包括索引键模式、遍历方向和索引边界等信息。

从 MongoDB 5.3 开始，如果查询规划器为集群化集合选择了集群化索引，且查询包含定义要搜索的索引部分的边界，则解释结果会包含一个 CLUSTERED_IXSCAN 阶段。该阶段包含有关集群化索引键和索引边界的信息。

如果查询规划器为集群化集合选择集群化索引，且查询不包含边界，则查询将执行无边界集合扫描，解释结果包括 COLLSCAN 阶段。

注意

notablescan 参数不允许使用集群索引的无界查询，因为这些查询需要完整的集合扫描。

有关集合扫描的执行统计数据的更多信息，请参阅解释“解释计划结果”。

覆盖查询

当索引涵盖查询时，MongoDB 可以仅使用索引键来匹配查询条件并返回结果。MongoDB 无需检查集合中的文档即可执行查询的任何部分。

当索引覆盖查询时，解释结果中有一个 IXSCAN 阶段不是 FETCH 阶段的子代，在 executionStats 中，explain.executionStats.totalDocsExamined 是 0。

`$or` 表达式(expression)

如果 MongoDB 为 $or 表达式使用索引，那么结果将包括 OR 阶段和一个详细说明索引的 explain.queryPlanner.winningPlan.inputStages 数组；例如：

{
   stage: 'OR',
   inputStages: [
      {
         stage: 'IXSCAN',
         ...
      },
      {
         stage : 'IXSCAN',
         ...
      },
      ...
   ]
}

在早期版本的 MongoDB 中，cursor.explain() 返回详细说明索引的 clauses 数组。

`$sort` 和 `$group` 阶段

当 explain 在 ExecutionStats 或 AllplansEx ecution 详细模式下运行时，$sort 和 $group 阶段会有额外的输出。

阶段	字段	类型	说明
`$sort`	`totalDataSizeSortedBytesEstimate`	long	`$sort` 阶段处理的字节估计数。
`$sort`	`usedDisk`	布尔	`$sort` 阶段是否已写入磁盘。
`$sort`	`spills`	long long	`$sort`阶段溢出到磁盘的次数。
`$sort`	`spilledBytes`	long long	压缩前在 `$sort` 阶段写入磁盘的字节估计数。
`$sort`	`spilledRecords`	long long	溢出到磁盘的单条记录总数。
`$sort`	`spilledDataStorageSize`	long long	溢出数据使用的总磁盘空间（以字节为单位）。
`$group`	`usedDisk`	布尔	`$group` 阶段是否已写入磁盘。
`$group`	`spills`	long long	`$group`阶段溢出到磁盘的次数。
`$group`	`spilledBytes`	long long	压缩前在 `$group` 阶段写入磁盘的字节估计数。
`$group`	`spilledRecords`	long long	溢出到磁盘的单条记录总数。
`$group`	`spilledDataStorageSize`	long long	溢出数据使用的总磁盘空间（以字节为单位）。

排序阶段

如果MongoDB无法使用一个或多个索引来获取排序顺序，则结果将包含一个指示内存中排序操作的 SORT 阶段。如果解释计划不包含显式 SORT 阶段，则MongoDB使用索引来获取排序顺序。

查询结构哈希

从 MongoDB 8.0 开始，explain 输出以下字段：

explain.queryShapeHash: 表示查询结构的哈希值的十六进制字符串。有关更多信息，请参阅查询结构。
8.0版本新增。

后退

分析查询性能

来年

解释结果

重要

注意

解释输出结构

解释 MongoDB 5.1 和更高版本的输出

queryPlanner

注意

executionStats

注意

警告

serverInfo

具有 $lookup 管道阶段的查询的执行计划统计信息

搜索查询的执行计划统计信息

集合扫描(collection scan)

注意

覆盖查询

$or 表达式(expression)

$sort 和 $group 阶段

排序阶段

查询结构哈希

`queryPlanner`

`executionStats`

`serverInfo`

具有 `$lookup` 管道阶段的查询的执行计划统计信息

`$or` 表达式(expression)

`$sort` 和 `$group` 阶段