Explain Results解释结果

queryPlanner

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

These examples may combine the output structures of MongoDB's classic and slot-based execution engines. 这些示例可以结合MongoDB的经典执行引擎和基于插槽的执行引擎的输出结构。They are not meant to be representative. Your output may differ significantly.它们并不具有代表性。您的输出可能存在显著差异。

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>,
   ]
}

{
   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 with the names of the database and the collection accessed by the query. 一个字符串，用于指定带有数据库名称和查询访问的集合名称的命名空间。The namespace has the format <database>.<collection>.命令空间的格式为<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。

explain.queryPlanner.planCacheKey

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

Unlike the explain.queryPlanner.queryHash, the explain.queryPlanner.planCacheKey is a function of both the query shape and the currently available indexes for that shape. 与explain.queryPlanner.queryHash不同，explain.queryPlanner.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。

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，则由于管道已被优化，因此输出中不会显示聚合阶段信息。

explain.queryPlanner.winningPlan

A document that details the plan selected by the query optimizer.详细说明查询优化器所选计划的文档。

explain.queryPlanner.winningPlan.stage

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

Each stage consists of information specific to the stage. For example, an IXSCAN stage includes 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或inputStages。

This field appears if the operation used the classic query execution engine.如果操作使用了经典查询执行引擎，则会显示此字段。

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 might consume input from multiple sources.例如，$or表达式的阶段可能会使用来自多个源的输入。

This field appears if the operation used the classic query execution engine.如果操作使用了经典查询执行引擎，则会显示此字段。

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将计划呈现为一个阶段树。

This document appears if the query used the slot-based execution query engine.如果查询使用基于槽的执行查询引擎，则会显示此文档。

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 example, an IXSCAN stage includes the index bounds along with other data specific to the index scan.每个阶段都包含特定于该阶段的信息。例如，IXSCAN阶段包括索引边界以及特定于索引扫描的其他数据。

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.queryPlan.inputStage

See explain.queryPlanner.winningPlan.inputStage.请参阅explain.queryPlanner.winningPlan.inputStage。

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.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 explain.executionStats information details the execution of the winning plan. 返回的explain.executionStats信息详细说明了获胜计划的执行情况。In order to include executionStats in the results, you must run the explain in either:为了在结果中包括executionStats，您必须在中运行解释：

• executionStats or或
• allPlansExecution verbosity mode. 冗长模式。Use allPlansExecution mode to include partial execution data captured during plan selection.使用allPlansExecution模式可以包括在计划选择期间捕获的部分执行数据。

These examples may combine the output structures of MongoDB's classic and slot-based execution engines. They are not meant to be representative. Your output may differ significantly.这些示例可以结合MongoDB的经典执行引擎和基于插槽的执行引擎的输出结构。它们并不具有代表性。您的输出可能存在显著差异。

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: {
                 ...
               }
            }
         }
      },
      ...
   ]
}

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. 选择查询计划和执行查询所需的总时间（以毫秒为单位）。explain.executionStats.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. 扫描的索引条目数。explain.executionStats.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

explain.executionStats.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, explain.executionStats.totalDocsExamined counts each examination. 如果在查询执行过程中多次检查文档，explain.executionStats.totalDocsExamined会对每次检查进行计数。That is, explain.executionStats.totalDocsExamined is not a count of the total number of unique documents examined.也就是说，explain.executionStats.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.查询执行将其工作划分为几个小单元。“工作单元”可能包括检查单个索引键、从集合中获取单个文档、对单个文档应用投影或进行内部记账。

This field appears if the operation used the classic query execution engine.如果操作使用了经典查询执行引擎，则会显示此字段。

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

Each inputStage can have different fields depending on the value of inputStage.stage. The following table describes possible fields and what stages they can appear in.根据inputStage.stage的值，每个inputStage可以有不同的字段。下表介绍了可能的字段以及它们可以出现在哪些阶段。

Each inputStage can have another inputStage as a field. 每个inputStage可以有另一个inputStage作为字段。See Explain Output Structure.请参阅解释输出结构。

Field字段	Description描述	Applicable Stages适用阶段
docsExamined	Specifies the number of documents scanned during the query execution stage.指定在查询执行阶段扫描的文档数。	COLLSCAN, FETCH
keysExamined	For query execution stages that scan an index keysExamined is the total number of in-bounds and out-of-bounds keys that are examined in the process of the index scan. 对于扫描索引的查询执行阶段，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.如果索引边界由多个键范围组成，则索引扫描执行过程可以检查越界键，以便从一个范围的末尾跳到下一个区域的开头。	IXSCAN
numReads	The number of documents scanned or index keys examined during the query execution stage. 在查询执行阶段扫描的文档数或检查的索引键数。 New in version 5.1. 5.1版新增。	COLLSCAN, IXSCAN
seeks	The number of times that we had to seek the index cursor to a new position in order to complete the index scan.为了完成索引扫描，我们必须将索引游标搜索到新位置的次数。	IXSCAN
spilledBytesApprox	The approximate number of in-memory bytes spilled to disk in the stage. 阶段中溢出到磁盘的内存中字节的大致数量。 New in version 5.3. 5.3版新增。	GROUP
spilledRecords	The number of produced records spilled to disk in the stage. 阶段中溢出到磁盘的已生成记录数。 New in version 5.3. 5.3版新增。	GROUP
usedDisk	Whether the stage wrote to disk. 阶段是否写入磁盘。 New in version 5.3. 5.3版新增。	GROUP

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详细模式下运行时，该字段才存在。

serverInfo

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

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>
 }
 ...