/ /

解释结果

为了返回有关查询计划和查询计划执行统计信息，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 信息详细说明了查询优化器选择的计划。

注意

从 MongoDB 8.3 开始，多计划同 CBR 备份是符合条件的查询的默认计划选择机制。在短暂的试用期间，多计划器会尝试找到能在这个短暂时间内返回结果集的计划。如果尝试失败，MongoDB 会应用一系列规则来确定多计划器是否应继续，或者 CBR 是否应评估计划中的每个节点以确定最优计划。

有关更多信息，请参阅查询计划选项。

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

对于未分片的集合，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>,
            ]
         }
         ]
      }
   }
}

如果查询优化器使用基于成本的排名器，则输出包含几个附加字段。

{
   queryPlanner: {
      mongosPlannerVersion: <int>
      winningPlan: {
         isCached: <boolean>,
         stage: <STAGE1>,
         costEstimate: <float>,
         cardinalityEstimate: <float>,
         estimatesMetadata: { ceSource: '<string>' },
         inputStage: {
           stage: <STAGE1>,
           costEstimate: <float>,
           cardinalityEstimate: <float>,
           filterNumKeysEstimate: <float>,
           numKeysEstimate: <float>,
           estimatesMetadata: { ceSource: '<string>'} ,
           ...
         }
      }
   }
}

explain.queryPlanner

包含查询优化器所选查询计划的相关信息。

explain.queryPlanner.namespace: 一个字符串，使用数据库的名称和查询访问的集合指定该命名空间。该命名空间的格式为 <database>.<collection>。

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

explain.queryPlanner.querySettings

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

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

8.0版本新增。：

explain.queryPlanner.planCacheShapeHash

一个十六进制字符串，表示计划缓存查询结构的哈希值，并且仅依赖于计划缓存查询结构。planCacheShapeHash 可以帮助识别具有相同计划缓存查询结构的慢查询（包括写入操作的查询筛选条件）。

注意

与任何哈希函数一样，两个不同的计划缓存查询结构可能会产生相同的哈希值。但是，不同计划缓存查询结构之间不太可能发生哈希冲突。

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

explain.queryPlanner.planCacheKey

与此查询关联的计划缓存条目的键的哈希值。

与 explain.queryPlanner.planCacheShapeHash 不同，explain.queryPlanner.planCacheKey 是计划缓存查询结构和该结构当前可用索引的函数。具体来说，如果添加或删除可以支持查询结构的索引，则 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.costEstimate: 代表每个阶段用于执行基于成本排名器的估计抽象成本单位的浮点。基于成本的排名器选择具有最低顶级 costEstimate 的计划。
8.3.3版本新增。：

explain.queryPlanner.winningPlan.cardinalityEstimate: 代表成本基于排名器阶段产生的估计文档或密钥数的浮点。
8.3.3版本新增。：

explain.queryPlanner.winningPlan.numKeysEstimate

表示查询计划程序预测计划处理的索引密钥的估计数量的浮点数。

numKeysEstimate 和 costEstimate 之间的显著差异可能表明 winningPlan 存在问题。

8.3.3版本新增。：

explain.queryPlanner.winningPlan.numDocsEstimate: 表示扫描的文档估计数的浮点数。
8.3.3版本新增。：

explain.queryPlanner.winningPlan.estimatesMetadata: 包含有关估算如何得出的元数据。
8.3.3版本新增。：

explain.queryPlanner.winningPlan.estimatesMetadata.ceSource

此阶段使用的关联基数估计方法 (CE)。可能的浮点值包括：

sampling: MongoDB 会在基础集合的示例上计算估计。
heuristics: 使用一组规则来确定选择性。仅在采样失败时使用。
mixed：该估计是某些计算的结果，该计算混合了不同类型的估计。
metadata: 估计来自数据库元数据，例如集合关联基数。
code: C++ 直接计算估计值，例如常量或表达式。

8.3.3版本新增。：

explain.queryPlanner.winningPlan.queryPlan

一份详细说明查询优化器所选计划的文档。MongoDB 将计划表示为阶段树。

如果查询使用基于槽位的执行查询引擎，则此文档出现。

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>,
         peakTrackedMemBytes: <long>, // Starting in 8.3
         ...
         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>
   }
},
...
peakTrackedMemBytes: <long>, // Starting in 8.3
...

对于分片集合，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>,
                  peakTrackedMemBytes: <long>, // Starting in 8.3
                  ...
                  inputStage: {
                     ...
                  }
               }
            }
         },
         ...
      ]
   }
   allPlansExecution: [
      {
         shardName: <string>,
         allPlans: [
            {
               nReturned: <int>,
               executionTimeMillisEstimate: <int>,
               peakTrackedMemBytes: <long>, // Starting in 8.3
               totalKeysExamined: <int>,
               totalDocsExamined:<int>,
               executionStages: {
                  stage: <STAGEA>,
                  nReturned: <int>,
                  executionTimeMillisEstimate: <int>,
                  ...
                  inputStage: {
                     stage: <STAGEB>,
                     ...
                     inputStage: {
                       ...
                     }
                  }
               }
            },
            ...
         ]
      },
      {
         shardName: <string>,
         allPlans: [
          ...
         ]
      },
      ...
   ],
   peakTrackedMemBytes: <long>, // Starting in 8.3
   ...
}

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

8.3版本新增。：

当前查询操作使用的跟踪内存的最大字节数。

解释执行统计信息提供了整个查询以及每个阻塞阶段的峰值内存。如果只有一个阻塞阶段，则查询和阶段 peakTrackedMemBytes 值相同。

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.score: 表示多规划器选择的获胜规划分数的 double。
8.3.3版本新增。：

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`
`peakTrackedMemBytes`	8.3版本新增。：当前查询操作使用的跟踪内存的最大字节数。	`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 阶段的后代。

`$or` 表达式(expression)

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

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

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

具有溢出指标的聚合阶段

当 explain 在executionStats 或 allPlansExecution 详细模式下运行时，某些可能溢出到磁盘的聚合阶段会产生额外的输出。这些阶段包括 $sort、$group、$setWindowFields、$bucketAuto、$graphLookup 和 $lookup（使用基于槽的执行引擎时）。

阶段	字段	类型	说明
`$sort`	`totalDataSizeSorted`	long	`$sort` 阶段处理的字节估计数。
`$sort`、`$group`、`$setWindowFields`、`$bucketAuto`、`$graphLookup`、`$lookup`（仅限 SBE）	`usedDisk`	布尔	该阶段是否已写入磁盘。
`$sort`、`$group`、`$setWindowFields`、`$bucketAuto`、`$graphLookup`、`$lookup`（仅限 SBE）	`spills`	long long	该阶段溢出到磁盘的次数。
`$sort`、`$group`、`$setWindowFields`、`$bucketAuto`、`$graphLookup`、`$lookup`（仅限 SBE）	`spilledBytes`	long long	压缩前写入磁盘的估计字节数。
`$sort`、`$group`、`$setWindowFields`、`$bucketAuto`、`$graphLookup`、`$lookup`（仅限 SBE）	`spilledRecords`	long long	溢出到磁盘的单条记录总数。
`$sort`、`$group`、`$setWindowFields`、`$bucketAuto`、`$graphLookup`、`$lookup`（仅限 SBE）	`spilledDataStorageSize`	long long	溢出数据使用的总磁盘空间（以字节为单位）。
`$sort`、`$group`、`$setWindowFields`、`$bucketAuto`、`$graphLookup`、`$lookup`（仅限 SBE）	`peakTrackedMemBytes`	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)

具有溢出指标的聚合阶段

排序阶段

查询结构哈希

`queryPlanner`

`executionStats`

`serverInfo`

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

`$or` 表达式(expression)