Explain Results解释结果

On this page本页内容

To return information on query plans and execution statistics of the query plans, MongoDB provides:为了返回查询计划的信息和查询计划的执行统计信息，MongoDB提供：

This page shows the output for the explain results in different versions of MongoDB.此页面显示不同版本MongoDB中解释结果的输出。

Note注意
  • Only the most important output fields are shown on this page.本页仅显示最重要的输出字段。
  • The output is subject to change.输出可能会发生变化。

Explain Output Structure解释输出结构

The explain results present the query plans as a tree of stages.explain结果将查询计划呈现为一个阶段树。

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

Each stage passes its resulting documents or index keys to the parent node. 每个阶段都将其生成的文档或索引键传递给父节点。The leaf nodes access the collection or the indices. 叶节点访问集合或索引。The internal nodes manipulate the documents or the index keys that result from the child nodes. 内部节点操作子节点生成的文档或索引键。The root node is the final stage from which MongoDB derives the result set.根节点是MongoDB获得结果集的最后一个阶段。

Stages are descriptive of the operation. For example:阶段是对操作的描述。例如：

  • COLLSCAN for a collection scan用于集合扫描
  • IXSCAN for scanning index keys用于扫描索引键
  • FETCH for retrieving documents用于检索文档
  • GROUP for grouping douments with $group用于利用$group对文档进行分组
  • SHARD_MERGE for merging results from shards用于合并分片的结果
  • SHARDING_FILTER for filtering out orphan documents from shards用于从分片中筛选出孤立文档

Explain Output for MongoDB 5.1 and Later解释MongoDB 5.1及更高版本的输出

New in version 5.1.在版本5.1中新增。

This section shows the explain output for MongoDB 5.1 and later.本节显示MongoDB 5.1及更高版本的explain输出。

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

Integer field with the explain planner version.解释计划器版本的整数字段。

explainVersion is:

  • 1 when slot based query execution is not used.1当不使用基于插槽的查询执行时。
  • 2 when slot based query execution is used.2.使用基于时隙的查询执行时。

New in version 5.1.在版本5.1中新增。

explain.queryPlanner.winningPlan.queryPlan

A document that details the plan selected by the query optimizer. 详细说明查询优化器选择的计划的文档。MongoDB presents the plan as a tree of stages.MongoDB以阶段树的形式展示了该计划。

New in version 5.1.在版本5.1中新增。

explain.queryPlanner.winningPlan.queryPlan.stage

A string that denotes the name of the stage.表示阶段名称的字符串。

Each stage consists of information specific to the stage. 每个阶段都包含特定于该阶段的信息。For instance, an IXSCAN stage will include the index bounds along with other data specific to the index scan.例如，IXSCAN阶段将包括索引边界以及特定于索引扫描的其他数据。

Starting in MongoDB 5.2, MongoDB can execute $group stages using the slot-based execution query engine. 从MongoDB 5.2开始，MongoDB可以使用基于插槽的执行查询引擎执行$group阶段。When the slot-based engine is used for $group, this field value is GROUP.当基于插槽的引擎用于$group时，此字段值为GROUP。

explain.queryPlanner.winningPlan.queryPlan.planNodeId

Unique integer field that identifies each stage in the execution plan. 标识执行计划中每个阶段的唯一整数字段。Field is included in all stages throughout the explain results.字段包含在explain结果的所有阶段中。

New in version 5.1.在版本5.1中新增。

explain.queryPlanner.winningPlan.slotBasedPlan

Document with information about the slot based query execution plan tree and stages.包含基于插槽的查询执行计划树和阶段信息的文档。

New in version 5.1.在版本5.1中新增。

Explain Output for MongoDB 4.4 and Earlier解释MongoDB 4.4及更早版本的输出

This section shows the explain output for MongoDB 4.4 and earlier.本节显示MongoDB 4.4及更早版本的explain输出。

This list presents some of the key fields returned by the explain operation.此列表显示explain操作返回的一些关键字段。

queryPlanner

queryPlanner information details the plan selected by the query optimizer.信息详细说明了查询优化器选择的计划。

For unsharded collections, explain returns the following queryPlanner information:对于未排序的集合，explain返回以下queryPlanner信息：

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

For sharded collections, explain includes the core query planner and server information for each accessed shard in the shards field:对于分片集合，explain包括shards字段中每个访问分片的核心查询规划器和服务器信息：

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

Contains information on the selection of the query plan by the query optimizer.包含有关查询优化器选择查询计划的信息。

explain.queryPlanner.namespace

A string that specifies the namespace (i.e., <database>.<collection>) against which the query is run.一个字符串，指定对其运行查询的命名空间（即，<database>.<collection>）。

explain.queryPlanner.indexFilterSet

A boolean that specifies whether MongoDB applied an index filter for the query shape.一个布尔值，指定MongoDB是否为查询形应用了索引筛选器。

explain.queryPlanner.queryHash

A hexadecimal string that represents the hash of the query shape and is dependent only on the query shapes. 一个十六进制字符串，表示查询形状的哈希值，仅依赖于查询形状。queryHash can help identify slow queries (including the query filter of write operations) with the same query shape.可以帮助识别具有相同查询形状的慢速查询（包括写操作的查询筛选器）。

Note注意

As with any hash function, two different query shapes may result in the same hash value. 与任何哈希函数一样，两个不同的查询形状可能会产生相同的哈希值。However, the occurrence of hash collisions between different query shapes is unlikely.但是，不同查询形状之间不太可能发生哈希冲突。

For more information on queryHash and planCacheKey, see queryHash and planCacheKey.有关queryHash和planCacheKey的更多信息，请参阅queryHash和planCacheKey。

New in version 4.2.在版本4.2中新增。

explain.queryPlanner.planCacheKey

A hash of the key for the plan cache entry associated with the query.与查询关联的计划缓存项的密钥哈希。

Unlike the queryHash, the planCacheKey is a function of both the query shape and the currently available indexes for that shape. 与queryHash不同，planCacheKey是查询形状和该形状当前可用索引的函数。That is, if indexes that can support the query shape are added/dropped, the planCacheKey value may change whereas the queryHash value would not change.也就是说，如果添加/删除支持查询形状的索引，planCacheKey值可能会更改，而queryHash值不会更改。

For more information on queryHash and planCacheKey, see queryHash and planCacheKey.有关queryHash和planCacheKey的更多信息，请参阅queryHash和planCacheKey。

New in version 4.2.在版本4.2中新增。

explain.queryPlanner.optimizedPipeline

A boolean that indicates that the entire aggregation pipeline operation was optimized away, and instead, fulfilled by a tree of query plan execution stages.一个布尔值，指示整个聚合管道操作已优化，而是由查询计划执行阶段树来完成。

For example, starting in MongodB 4.2, the following aggregation operation can be fulfilled by the tree of query plan execution rather than using the aggregation pipeline.例如，从MongodB 4.2开始，以下聚合操作可以通过查询计划执行树来完成，而不是使用聚合管道。

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

The field is only present if the value is true and only applies to explain on aggregation pipeline operations. 仅当该值为true时，该字段才存在，并且仅适用于解释聚合管道操作。When true, because the pipeline was optimized away, no aggregation stage information appears in the output.如果为true，则由于管道已优化，因此输出中不会出现聚合阶段信息。

New in version 4.2.在版本4.2中新增。

explain.queryPlanner.winningPlan

A document that details the plan selected by the query optimizer. 详细说明查询优化器选择的计划的文档。MongoDB presents the plan as a tree of stages; i.e. a stage can have an inputStage or, if the stage has multiple child stages, inputStages.MongoDB将该计划呈现为一棵阶段树；也就是说，一个阶段可以有一个inputStage，如果该阶段有多个子阶段，则可以有inputStages。

explain.queryPlanner.winningPlan.stage

A string that denotes the name of the stage.表示舞台名称的字符串。

Each stage consists of information specific to the stage. 每个阶段都包含特定于该阶段的信息。For instance, an IXSCAN stage will include the index bounds along with other data specific to the index scan. 例如，IXSCAN阶段将包括索引边界以及特定于索引扫描的其他数据。If a stage has a child stage or multiple child stages, the stage will have an inputStage or inputStages.如果一个阶段有一个子阶段或多个子阶段，该阶段将有一个或多个inputStage。

explain.queryPlanner.winningPlan.inputStage

A document that describes the child stage, which provides the documents or index keys to its parent. 描述子阶段的文档，它向其父阶段提供文档或索引键。The field is present if the parent stage has only one child.如果父阶段只有一个子阶段，则该字段存在。

explain.queryPlanner.winningPlan.inputStages

An array of documents describing the child stages. 描述子阶段的一系列文档。Child stages provide the documents or index keys to the parent stage. 子阶段为父阶段提供文档或索引键。The field is present if the parent stage has multiple child nodes. 如果父阶段有多个子节点，则该字段存在。For example, stages for $or expressions or index intersection consume input from multiple sources.例如，$or表达式或索引交集的阶段使用来自多个源的输入。

explain.queryPlanner.rejectedPlans

Array of candidate plans considered and rejected by the query optimizer. 查询优化器考虑并拒绝的候选计划数组。The array can be empty if there were no other candidate plans.如果没有其他候选计划，数组可以为空。

executionStats

The returned executionStats information details the execution of the winning plan. 返回的executionStats信息详细说明了获胜计划的执行情况。In order to include executionStats in the results, you must run the explain in either:为了在结果中包含executionStats，您必须在以下任一位置运行解释：

For unsharded collections, explain returns the following executionStats information:对于未记录的集合，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>,
         ...
         inputStage: {
            ...
         }
      }
   },
   allPlansExecution: [
      {
         nReturned: <int>,
         executionTimeMillisEstimate: <int>,
         totalKeysExamined: <int>,
         totalDocsExamined:<int>,
         executionStages: {
            stage: <STAGEA>,
            nReturned: <int>,
            executionTimeMillisEstimate: <int>,
            ...
            inputStage: {
               stage: <STAGEB>,
               ...
               inputStage: {
                 ...
               }
            }
         }
      },
      ...
   ]
}

For sharded collections, explain includes the execution statistics for each accessed shard.对于分片集合，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
                  ...
                  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

Contains statistics that describe the completed query execution for the winning plan. 包含描述获胜计划的已完成查询执行的统计信息。For write operations, completed query execution refers to the modifications that would be performed, but does not apply the modifications to the database.对于写操作，已完成的查询执行指的是将要执行的修改，但不会将修改应用于数据库。

explain.executionStats.nReturned

Number of documents that match the query condition. 符合查询条件的文档数。nReturned corresponds to the n field returned by cursor.explain() in earlier versions of MongoDB.对应于早期版本MongoDB中cursor.explain()返回的n字段。

explain.executionStats.executionTimeMillis

Total time in milliseconds required for query plan selection and query execution. 查询计划选择和查询执行所需的总时间（毫秒）。executionTimeMillis corresponds to the millis field returned by cursor.explain() in earlier versions of MongoDB.对应于早期版本MongoDB中cursor.explain()返回的millis（毫秒）字段。

explain.executionStats.totalKeysExamined

Number of index entries scanned. 扫描的索引项数。totalKeysExamined corresponds to the nscanned field returned by cursor.explain() in earlier versions of MongoDB.对应于早期版本MongoDB中cursor.explain()返回的nscanned字段。

explain.executionStats.totalDocsExamined

Number of documents examined during query execution. 查询执行期间检查的文档数。Common query execution stages that examine documents are COLLSCAN and FETCH.检查文档的常见查询执行阶段是COLLSCAN和FETCH。

Note注意

totalDocsExamined refers to the total number of documents examined and not to the number of documents returned. 指检查的文件总数，而不是返回的文件数。For example, a stage can examine a document in order to apply a filter. 例如，阶段可以检查文档以应用筛选器。If the document is filtered out, then it has been examined but will not be returned as part of the query result set.如果文档被筛选掉，那么它已被检查，但不会作为查询结果集的一部分返回。

If a document is examined multiple times during query execution, totalDocsExamined counts each examination. 如果在查询执行期间多次检查文档，则totalDocsExamined会对每次检查进行计数。That is, totalDocsExamined is not a count of the total number of unique documents examined.也就是说，totalDocsExamined不是检查的唯一文档总数的计数。

explain.executionStats.executionStages

Details the completed execution of the winning plan as a tree of stages; i.e. a stage can have an inputStage or multiple inputStages.以阶段树的形式详细说明获胜计划的完成执行情况；一个阶段可以有一个inputStage或多个inputStages。

Starting in MongoDB 5.1, a stage can have these input stages:从MongoDB 5.1开始，阶段可以有以下输入阶段：

  • thenStage
  • elseStage
  • innerStage
  • outerStage

Each stage consists of execution information specific to the stage.每个阶段都包含特定于该阶段的执行信息。

explain.executionStats.executionStages.executionTimeMillisEstimate

The estimated amount of time in milliseconds for query execution.查询执行的估计时间（毫秒）。

explain.executionStats.executionStages.opens

Starting in MongoDB 5.1, the number of times a stage was opened during query execution.从MongoDB 5.1开始，查询执行期间打开阶段的次数。

explain.executionStats.executionStages.closes

Starting in MongoDB 5.1, the number of times a stage was closed during query execution.从MongoDB 5.1开始，查询执行期间阶段关闭的次数。

explain.executionStats.executionStages.works

Specifies the number of "work units" performed by the query execution stage. 指定查询执行阶段执行的“工作单元”数。Query execution divides its work into small units. 查询执行将其工作划分为几个小单元。A "work unit" might consist of examining a single index key, fetching a single document from the collection, applying a projection to a single document, or doing a piece of internal bookkeeping.“工作单元”可能包括检查单个索引键、从集合中提取单个文档、对单个文档应用投影，或者执行一项内部簿记。

Starting in MongoDB 5.1, this field is omitted.从MongoDB 5.1开始，省略此字段。

explain.executionStats.executionStages.nReturned

The number of intermediate results returned by this stage to its parent stage.此阶段返回给其父阶段的中间结果数。

Starting in MongoDB 5.1, this field is omitted.从MongoDB 5.1开始，省略此字段。

explain.executionStats.executionStages.needTime

The number of work cycles that did not advance an intermediate result to its parent stage (see explain.executionStats.executionStages.nReturned). 未将中间结果提前到其父阶段的工作周期数（请参阅解释explain.executionStats.executionStages.nReturned）。For instance, an index scan stage may spend a work cycle seeking to a new position in the index as opposed to returning an index key; this work cycle would count towards explain.executionStats.executionStages.needTime rather than explain.executionStats.executionStages.nReturned.例如，索引扫描阶段可以花费一个工作周期来寻找索引中的新位置，而不是返回索引键；此工作周期将计入explain.executionStats.executionStages.needTime ，而不是explain.executionStats.executionStages.nReturned。

Starting in MongoDB 5.1, this field is omitted.从MongoDB 5.1开始，省略此字段。

explain.executionStats.executionStages.needYield

The number of times that the storage layer requested that the query stage suspend processing and yield its locks.存储层请求查询阶段暂停处理并产生锁的次数。

Starting in MongoDB 5.1, this field is omitted.从MongoDB 5.1开始，省略此字段。

explain.executionStats.executionStages.saveState

The number of times that the query stage suspended processing and saved its current execution state, for example in preparation for yielding its locks.查询阶段暂停处理并保存其当前执行状态的次数，例如为产生锁做准备的次数。

explain.executionStats.executionStages.restoreState

The number of times that the query stage restored a saved execution state, for example after recovering locks that it had previously yielded.查询阶段恢复已保存的执行状态的次数，例如，在恢复以前生成的锁之后。

explain.executionStats.executionStages.isEOF

Specifies whether the execution stage has reached end of stream:指定执行阶段是否已到达流的末尾：

  • If true or 1, the execution stage has reached end-of-stream.如果为true或1，则执行阶段已到达流的末尾。
  • If false or 0, the stage may still have results to return. 如果为false或0，该阶段可能仍有结果要返回。For example, consider a query with a limit whose execution stages consists of a LIMIT stage with an input stage of IXSCAN for the query. 例如，考虑一个具有限制的查询，其执行阶段由一个LIMIT阶段组成，该查询的输入阶段为IXSCAN。If the query returns more than the specified limit, the LIMIT stage will report isEOF: 1, but its underlying IXSCAN stage will report isEOF: 0.如果查询返回的值超过指定的限制，LIMIT阶段将报告isEOF:1，但其基础IXSCAN阶段将报告isEOF:0。
explain.executionStats.executionStages.inputStage.keysExamined

For query execution stages that scan an index (e.g. IXSCAN), keysExamined is the total number of in-bounds and out-of-bounds keys that are examined in the process of the index scan. 对于扫描索引的查询执行阶段（例如IXSCAN），keysExamined是在索引扫描过程中检查的界内键和界外键的总数。If the index scan consists of a single contiguous range of keys, only in-bounds keys need to be examined. 如果索引扫描由单个连续的键组成，则只需检查边界内的键。If the index bounds consists of several key ranges, the index scan execution process may examine out-of-bounds keys in order to skip from the end of one range to the beginning of the next.如果索引边界由多个键范围组成，则索引扫描执行过程可能会检查越界键，以便从一个范围的末尾跳到下一个范围的开头。

Consider the following example, where there is an index of field x and the collection contains 100 documents with x values 1 through 100:考虑以下示例，其中有一个字段x的索引，集合包含100个x值为1到100的文档：

db.keys.find( { x : { $in : [ 3, 4, 50, 74, 75, 90 ] } } ).explain( "executionStats" )

The query will scan keys 3 and 4. 查询将扫描键3和4。It will then scan the key 5, detect that it is out-of-bounds, and skip to the next key 50.然后，它将扫描键5，检测它是否超出范围，并跳到下一个键50。

Continuing this process, the query scans keys 3, 4, 5, 50, 51, 74, 75, 76, 90, and 91. 继续这个过程，查询将扫描键3、4、5、50、51、74、75、76、90和91。Keys 5, 51, 76, and 91 are out-of-bounds keys that are still examined. 键5、51、76和91是仍在检查的界外键。The value of keysExamined is 10.检查的键的值为10。

explain.executionStats.executionStages.inputStage.docsExamined

Specifies the number of documents scanned during the query execution stage.指定在查询执行阶段扫描的文档数。

Present for the COLLSCAN stage, as well as for stages that retrieve documents from the collection (e.g. FETCH)用于COLLSCAN阶段，以及从集合中检索文档的阶段（例如FETCH）

explain.executionStats.executionStages.inputStage.seeks

For index scan (IXSCAN) stages only.仅适用于索引扫描（IXSCAN）阶段。

The number of times that we had to seek the index cursor to a new position in order to complete the index scan.为了完成索引扫描，我们必须将索引游标搜索到新位置的次数。

explain.executionStats.executionStages.inputStage.numReads

New in version 5.1.在版本5.1中新增。

The number of documents scanned or index keys examined during the query execution stage. 在查询执行阶段扫描的文档数或检查的索引键数。Included for scan, seek, ixscan, and ixseek stages.包括scan、seek、ixscan和ixseek阶段。

explain.executionStats.allPlansExecution

Contains partial execution information captured during the plan selection phase for both the winning and rejected plans. 包含在计划选择阶段为成功计划和被拒绝计划捕获的部分执行信息。The field is present only if explain runs in allPlansExecution verbosity mode.仅当explain在allPlansExecution详细模式下运行时，该字段才会出现。

Execution Plan Statistics for Query with $lookup Pipeline Stage使用$lookup管道阶段查询的执行计划统计信息

New in version 5.0.在版本5.0中新增。

The explain results can include execution statistics for queries that use a $lookup pipeline stage. 解释结果可以包括使用$lookup管道阶段的查询的执行统计信息。To include those execution statistics, you must run the explain operation in one of these execution verbosity modes:要包含这些执行统计信息，必须在以下执行详细度模式之一下运行explain操作：

The following fields are included in the explain results for a $lookup query:以下字段包含在$lookup查询的解释结果中：

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

To see the descriptions for the fields in the $lookup section, see the $lookup page.要查看$lookup部分中字段的描述，请参阅$lookup页面。

The other fields are:其他字段包括：

explain.totalDocsExamined

Number of documents examined during the query execution.查询执行期间检查的文档数。

explain.totalKeysExamined

Number of index keys examined.检查的索引键数。

explain.collectionScans

Number of times a collection scan occurred during query execution. 查询执行期间发生集合扫描的次数。During a collection scan, each document in a collection is compared to the query predicate. 在集合扫描期间，将集合中的每个文档与查询谓词进行比较。Collection scans occur if no appropriate index exists that covers the query.如果不存在覆盖查询的适当索引，则会进行集合扫描。

explain.indexesUsed

Array of strings with the names of the indexes used by the query.包含查询使用的索引名称的字符串数组。

explain.nReturned

Number of documents that match the query condition.符合查询条件的文档数。

explain.executionTimeMillisEstimate

Estimated time in milliseconds for the query execution.查询执行的估计时间（毫秒）。

serverInfo

For unsharded collections, explain returns the following serverInfo information for the MongoDB instance:对于未分级的集合，explain返回MongoDB实例的以下serverInfo信息：

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

For sharded collections, explain returns the serverInfo for each accessed shard, and a top-level serverInfo object for the mongos.对于分片集合，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>
 }
 ...

Collection Scan集合扫描

If the query planner selects a collection scan, the explain result includes a COLLSCAN stage.如果查询计划器选择集合扫描，则解释结果包括COLLSCAN阶段。

If the query planner selects an index, the explain result includes a IXSCAN stage. 如果查询计划器选择索引，解释结果将包括一个IXSCAN阶段。The stage includes information such as the index key pattern, direction of traversal, and index bounds.该阶段包括索引键模式、遍历方向和索引边界等信息。

For more information on execution statistics of collection scans, see Analyze Query Performance.有关集合扫描的执行统计信息的更多信息，请参阅分析查询性能。

Covered Queries覆盖查询

When an index covers a query, MongoDB can both match the query conditions and return the results using only the index keys; i.e. MongoDB does not need to examine documents from the collection to return the results.当索引覆盖查询时，MongoDB既可以匹配查询条件，也可以只使用索引键返回结果；亦即MongoDB不需要检查集合中的文档来返回结果。

When an index covers a query, the explain result has an IXSCAN stage that is not a descendant of a FETCH stage, and in the executionStats, the totalDocsExamined is 0.当索引覆盖查询时，解释结果有一个IXSCAN阶段，它不是FETCH阶段的后代，在executionStats中，totalDocsExamined为0。

Index Intersection索引交点

For an index intersection plan, the result will include either an AND_SORTED stage or an AND_HASH stage with an inputStages array that details the indexes; e.g.:对于索引交叉点计划，结果将包括AND_SORTEDAND_HASH阶段，以及详细说明索引的inputStages数组；如。：

{
   "stage" : "AND_SORTED",
   "inputStages" : [
      {
         "stage" : "IXSCAN",
         ...
      },
      {
         "stage" : "IXSCAN",
         ...
      }
   ]
}

$or Expression表示

If MongoDB uses indexes for an $or expression, the result will include the OR stage with an inputStages array that details the indexes; e.g.:如果MongoDB对$or表达式使用索引，结果将包括OR阶段，以及详细说明索引的inputStages数组；如：

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

In previous versions of MongoDB, cursor.explain() returned the clauses array that detailed the indexes.在MongoDB的早期版本中，cursor.explain()返回详细说明索引的clauses数组。

$sort and $group Stages$sort阶段和$group阶段

When explain is run in either executionStats or allPlansExecution verbosity mode, the $sort and $group stages have additional output.在executionStats或allPlansExecution详细模式下运行explain时，$sort和$group阶段会有额外的输出。

Stage阶段Field字段Type类型Description描述
$sorttotalDataSizeSortedBytesEstimatelongAn estimated number of bytes processed in the $sort stage.$sort阶段中处理的估计字节数。
$sortusedDiskbooleanWhether the $sort stage wrote to disk.$sort阶段是否写入磁盘。
$grouptotalOutputDataSizeByteslongAn estimate of the total size of all documents output by the $group stage in bytes.对$group阶段输出的所有文档的总大小的估计，以字节为单位。
$groupusedDiskbooleanWhether the $group stage wrote to disk.$group阶段是否写入磁盘。

Sort Stage排序阶段

If MongoDB cannot use an index or indexes to obtain the sort order, the results include a SORT stage indicating a blocking sort operation. 如果MongoDB无法使用一个或多个索引来获取排序顺序，那么结果将包括一个表示阻塞排序操作的排序阶段。Blocking sorts do not block concurrent operations on the collection or database. 阻止排序不会阻止集合或数据库上的并发操作。The name refers to the requirement that the SORT stage reads all input documents before returning any output documents, blocking the flow of data for that specific query.该名称指的是SORT阶段在返回任何输出文档之前读取所有输入文档的要求，从而阻止特定查询的数据流。

If MongoDB requires using more than 100 megabytes of system memory for the blocking sort operation, MongoDB returns an error unless the query specifies cursor.allowDiskUse() (New in MongoDB 4.4). 如果MongoDB需要使用超过100 MB的系统内存来执行阻塞排序操作，MongoDB将返回一个错误，除非查询指定cursor.allowDiskUse()（MongoDB 4.4中新增）。allowDiskUse() allows MongoDB to use temporary files on disk to store data exceeding the 100 megabyte system memory limit while processing a blocking sort operation. 允许MongoDB在处理阻塞排序操作时，使用磁盘上的临时文件存储超过100 MB系统内存限制的数据。If the explain plan does not contain an explicit SORT stage, then MongoDB can use an index to obtain the sort order.如果解释计划不包含显式SORT阶段，那么MongoDB可以使用索引来获取排序顺序。

←  Write Operation PerformanceQuery Plans →