参考 > MongoDB CRUD操作 > MongoDB CRUD概念 > 查询优化 > 说明结果
要返回有关查询计划的信息和查询计划的执行统计信息,MongoDB提供:
db.collection.explain()
方法,cursor.explain()
方法,和explain
命令。该explain
结果呈现的查询计划,作为阶段的树。
每个阶段将其结果(即文档或索引键)传递给父节点。叶节点访问集合或索引。内部节点操纵由子节点产生的文档或索引键。根节点是MongoDB从中得出结果集的最后阶段。
阶段描述了操作;例如
COLLSCAN
用于集合扫描IXSCAN
用于扫描索引键FETCH
用于检索文件SHARD_MERGE
用于合并分片的结果SHARDING_FILTER
用于从分片中筛选出孤立文档以下各节列出了该explain
操作返回的一些关键字段。
注意
queryPlanner
¶queryPlanner
信息详细说明了查询优化器选择的计划。
对于未分片的集合,explain
返回以下
queryPlanner
信息:
对于分片集合,explain
在shards
字段中包括每个访问的分片的核心查询计划器和服务器信息:
explain.
queryPlanner
¶包含有关查询优化器选择查询计划的信息 。
explain.queryPlanner.
namespace
¶一个字符串,它指定<database>.<collection>
要对其运行查询的名称空间(即
)。
explain.queryPlanner.
queryHash
¶一个十六进制字符串,代表查询形状的哈希,
并且仅取决于查询形状。
queryHash
可以帮助识别具有相同查询形状的慢查询(包括写操作的查询过滤器)。
注意
与任何哈希函数一样,两个不同的查询形状可能会导致相同的哈希值。但是,不同查询形状之间不会发生哈希冲突。
有关详细信息queryHash
,并planCacheKey
请参阅queryHash和planCacheKey。
4.2版中的新功能。
explain.queryPlanner.
planCacheKey
¶与查询关联的计划缓存条目的键的哈希值。
与不同的是queryHash
,
planCacheKey
是查询形状和该形状当前可用索引的函数。即,如果添加/删除了可以支持查询形状的索引,则该planCacheKey
值可能会更改,而该queryHash
值不会更改。
有关详细信息queryHash
,并planCacheKey
请参阅queryHash和planCacheKey。
4.2版中的新功能。
explain.queryPlanner.
optimizedPipeline
¶指示整个聚合管道操作已优化的布尔值,而是由查询计划执行阶段的树来完成。
例如,从MongodB 4.2开始,可以通过查询计划执行树来执行以下聚合操作,而不是使用聚合管道。
仅当该值为true
且仅用于解释聚合管道操作时,才显示该字段。当使用时
true
,由于已对管道进行了优化,因此在输出中不会显示任何聚合阶段信息。
4.2版中的新功能。
explain.queryPlanner.
winningPlan
¶详细说明查询优化器选择的计划的文档。MongoDB以阶段树的形式展示了该计划。也就是说,一个阶段可以具有,
inputStage
或者,如果该阶段具有多个子阶段,则可以
inputStages
。
explain.queryPlanner.winningPlan.
stage
¶表示舞台名称的字符串。
每个阶段都包含特定于该阶段的信息。例如,一个IXSCAN
阶段将包括索引范围以及特定于索引扫描的其他数据。如果一个阶段具有一个子阶段或多个子阶段,那么该阶段将具有inputStage或inputStages。
explain.queryPlanner.winningPlan.
inputStage
¶描述子阶段的文档,该子阶段将文档或索引键提供给其父级。如果父阶段只有一个孩子,则该字段存在 。
explain.queryPlanner.
rejectedPlans
¶查询优化器考虑和拒绝的候选计划的数组。如果没有其他候选计划,则该数组可以为空。
executionStats
¶返回的executionStats
信息详细说明了获胜计划的执行情况。为了包括
executionStats
在结果中,您必须在以下任一位置运行解释:
allPlansExecution
模式包括计划选择期间捕获的部分执行数据。对于未分片的集合,explain
返回以下
executionStats
信息:
对于分片集合,explain
包括每个访问的分片的执行统计信息。
explain.
executionStats
¶包含描述获胜计划的已完成查询执行的统计信息。对于写操作,完成查询执行指的是修改将被执行,但并 没有修改应用到数据库。
explain.executionStats.
nReturned
¶符合查询条件的文档数。
nReturned
对应于MongoDB早期版本中n
返回的字段cursor.explain()
。
explain.executionStats.
executionTimeMillis
¶选择查询计划和执行查询所需的总时间(以毫秒为单位)。executionTimeMillis
对应于MongoDB早期版本中millis
返回的字段cursor.explain()
。
explain.executionStats.
totalKeysExamined
¶扫描的索引条目数。
totalKeysExamined
对应于MongoDB早期版本中nscanned
返回的
字段cursor.explain()
。
explain.executionStats.
totalDocsExamined
¶查询执行期间检查的文档数。检查文档的常见查询执行阶段是COLLSCAN
和FETCH
。
注意
totalDocsExamined
是指检查的文件总数,而不是指退回的文件数。例如,阶段可以检查文档以应用过滤器。如果文档被过滤掉,则说明该文档已经过检查,但不会作为查询结果集的一部分返回。
如果在查询执行期间对文档进行了多次totalDocsExamined
检查,则
对每次检查进行计数。也就是说,
totalDocsExamined
是不是总次数的计数独特的研究文件。
explain.executionStats.
executionStages
¶以阶段树的形式详细说明获胜计划的完成执行情况;即一个阶段可以有一个inputStage
或多个
inputStages
。
每个阶段都包含特定于该阶段的执行信息。
explain.executionStats.executionStages.
works
¶指定查询执行阶段执行的“工作单位”的数量。查询执行将其工作分为几个小单元。“工作单元”可能包括检查单个索引键,从集合中获取单个文档,对单个文档应用投影或进行内部簿记。
explain.executionStats.executionStages.
advanced
¶的中间结果的数目返回,或先进的,通过这个阶段到其父阶段。
explain.executionStats.executionStages.
needTime
¶没有将中间结果提前到其父阶段的工作周期数(请参阅参考资料
explain.executionStats.executionStages.advanced
)。例如,索引扫描阶段可能会花费一个工作周期来寻找索引中的新位置,而不是返回索引键。这个工作周期将计入explain.executionStats.executionStages.needTime
而非计入
explain.executionStats.executionStages.advanced
。
explain.executionStats.executionStages.
needYield
¶存储层请求查询阶段挂起处理并产生其锁的次数。
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.inputStage.
keysExamined
¶对于扫描索引的查询执行阶段(例如IXSCAN),
keysExamined
是在索引扫描过程中检查的入站和出站键的总数。如果索引扫描由单个连续范围的键组成,则仅需要检查入站键。如果索引范围由几个键范围组成,则索引扫描执行过程可能会检查越界键,以便从一个范围的末尾跳到下一个范围的末尾。
考虑下面的示例,其中有一个字段索引,
x
并且集合包含100个文档,其x
值从1到100:
查询将扫描键3
和4
。然后它将扫描密钥
5
,检测到它超出范围,然后跳到下一个密钥
50
。
继续这一过程中,查询扫描键3,4,5,50,51,74,75,76,90,和91键
5
,51
,76
,和91
被外的边界键仍在审查。的值为keysExamined
10。
explain.executionStats.executionStages.inputStage.
docsExamined
¶指定在查询执行阶段扫描的文档数。
呈现给该COLLSCAN
阶段以及从集合中检索文档的阶段(例如FETCH
)
explain.executionStats.executionStages.inputStage.
seeks
¶3.4版的新功能:仅适用于索引扫描(IXSCAN
)阶段。
为了完成索引扫描,我们必须将索引光标搜索到新位置的次数。
serverInfo
¶对于未分片的集合,explain
返回serverInfo
有关MongoDB实例的以下
信息:
对于分片集合,explain
返回
serverInfo
每个访问的分片的。
从MongoDB 3.0开始,结果的格式和字段explain
与以前的版本已更改。以下列出了一些主要区别。
如果查询计划者选择了收集扫描,则解释结果将包括一个COLLSCAN
阶段。
如果查询计划者选择了索引,则说明结果包括一个
IXSCAN
阶段。该阶段包括诸如索引键样式,遍历方向和索引边界之类的信息。
在以前的MongoDB版本中,cursor.explain()
返回的
cursor
字段值为:
BasicCursor
用于收集扫描,以及BtreeCursor <index name> [<direction>]
用于索引扫描。有关收集扫描和索引扫描的执行统计信息的更多信息,请参阅分析查询性能。
当索引涵盖查询时,MongoDB既可以匹配查询条件,也可以仅使用索引键返回结果;即MongoDB无需检查集合中的文档即可返回结果。
当索引覆盖查询时,解释结果的IXSCAN
阶段不是该阶段的后代FETCH
,而在
executionStats中,totalDocsExamined
is是0
。
在MongoDB的早期版本中,cursor.explain()
返回该
indexOnly
字段以指示索引是否包含查询。
对于索引交叉计划,结果将包括一个AND_SORTED
阶段或一个AND_HASH
包含inputStages
详细描述索引的数组的阶段。例如:
在以前的MongoDB版本中,cursor.explain()
返回cursor
值为index交集的
字段。Complex Plan