解释结果

queryPlanner

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

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

queryPlanner: {
   namespace: <string>,
   indexFilterSet: <boolean>,
   parsedQuery: {
      ...
   },
   planCacheShapeHash: <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: {
               ...
            },
            querySettings: {
               ...
            },
            planCacheShapeHash: <hexadecimal string>,
            planCacheKey: <hexadecimal string>,
            maxIndexedOrSolutionsReached: <boolean>,
            maxIndexedAndSolutionsReached: <boolean>,
            maxScansToExplodeReached: <boolean>,
            winningPlan: {
               stage: <STAGE1>,
               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

从 MongoDB 8.0 开始，预先存在的 queryHash 字段被重命名为 planCacheShapeHash。如果正在使用早期版本的 MongoDB，您将看到 queryHash 而不是 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 查询所花费的时间。

8.0版本新增。

explain.queryPlanner.optimizedPipeline

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

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

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

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

explain.queryPlanner.winningPlan

详细说明查询优化器所选计划的文档。

explain.queryPlanner.winningPlan.stage

一个表示阶段名称的字符串。

每个阶段都包含针对该阶段的信息。例如，IXSCAN 阶段包括索引边界和索引扫描的其他特定数据。如果一个阶段有一个或多个子阶段，则该阶段将有一个 inputStage 或 inputStages。

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

explain.queryPlanner.winningPlan.inputStage

一份描述该子阶段的文档，该子阶段为其父阶段提供文档或索引键。如果父阶段只有一个子阶段，则该字段存在。

explain.queryPlanner.winningPlan.inputStages

描述子阶段的一系列文档。子阶段为父阶段提供文档或索引键。如果父阶段有多个子节点，则该字段存在。例如，$or 表达式的阶段可能会消耗多个来源的输入。

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

explain.queryPlanner.winningPlan.isCached

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

对于获胜计划和被拒绝计划之间最多一个计划，此字段为true 。 如果查询没有缓存计划，则对于获胜计划和被拒绝的计划，该字段为false 。

explain.queryPlanner.winningPlan.queryPlan

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

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

5.1 版本中的新功能。

explain.queryPlanner.winningPlan.queryPlan.stage

一个表示阶段名称的字符串。

每个阶段都包含针对该阶段的信息。例如，IXSCAN 阶段包括索引边界和索引扫描的其他特定数据。

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 的经典执行引擎和基于槽位的执行引擎的输出结构。它们并不具有代表性。您的输出可能与之有巨大差异。

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

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

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

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
spilledBytesApprox	在该阶段中溢出到磁盘的内存字节大约数。 5.3 版本中的新增功能。	GROUP
spilledRecords	在该阶段中溢出到磁盘的生成记录数。 5.3 版本中的新增功能。	GROUP
usedDisk	该阶段是否已写入磁盘。 5.3 版本中的新增功能。	GROUP

explain.executionStats.allPlansExecution

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

explain.executionStats.operationMetrics

包含资源使用情况统计数据（只要该数据不为零）。仅当 explain 在 executionStats 详细模式或更高级别的模式下运行并且 profileOperationResourceConsumptionMetrics 处于启用状态时，此字段才会出现。

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