MongoDB 执行计划 mongodb性能分析方法：exp

发表于

mongodb性能分析方法：explain()

explain输出结果说明

在执行类似于 db.collections.find().explain() 时只会输出(返回)

1
2
3
js复制代码queryPlanner 
与 
serverInfo

在执行类似于 db.collections.find().explain() 时只会输出(返回)

1
2
3
js复制代码queryPlanner 
与 
serverInfo

而在执行类似于 db.collections.find().explain("executionStats") 或 db.collections.find().explain(1) 时则会输出(返回)

1
2
3
4
5
js复制代码queryPlanner 
与 
executionStats 
与 
serverInfo

queryPlanner

queryPlanner模式下并不会去真正进行query语句查询，而是针对query语句进行执行计划分析并选出winning plan。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
js复制代码queryPlanner: queryPlanner的返回

queryPlanner.namespace:该值返回的是该query所查询的表

queryPlanner.indexFilterSet:针对该query是否有indexfilter

queryPlanner.winningPlan:查询优化器针对该query所返回的最优执行计划的详细内容。

queryPlanner.winningPlan.stage:最优执行计划的stage，这里返回是FETCH，可以理解为通过返回的index位置去检索具体的文档（stage有数个模式，将在后文中进行详解）。

queryPlanner.winningPlan.inputStage:用来描述子stage，并且为其父stage提供文档和索引关键字。

queryPlanner.winningPlan.stage的child stage，此处是IXSCAN，表示进行的是index scanning。

queryPlanner.winningPlan.keyPattern:所扫描的index内容，此处是did:1,status:1,modify_time: -1与scid : 1

queryPlanner.winningPlan.indexName：winning plan所选用的index。

queryPlanner.winningPlan.isMultiKey是否是Multikey，此处返回是false，如果索引建立在array上，此处将是true。

queryPlanner.winningPlan.direction：此query的查询顺序，此处是forward，如果用了.sort({modify_time:-1})将显示backward。

queryPlanner.winningPlan.indexBounds:winningplan所扫描的索引范围,如果没有制定范围就是[MaxKey, MinKey]，这主要是直接定位到mongodb的chunck中去查找数据，加快数据读取。

queryPlanner.rejectedPlans：其他执行计划（非最优而被查询优化器reject的）的详细返回，其中具体信息与winningPlan的返回中意义相同，故不在此赘述。

executionStats

executionTimeMillis

executionStats.executionTimeMillis：指的是语句的执行整体时间

executionStats.executionStages.executionTimeMillis：该查询根据index去检索document获取nReturned条具体数据的时间

executionStats.executionStages.inputStage.executionTimeMillis：该查询扫描totalKeysExamined行index所用时间

nReturned、totalKeysExamined、totalDocsExamined

这些都是直观地影响到 executionTimeMillis，我们需要扫描的越少速度越快。

nReturne：该条查询返回的条目

totalKeysExamined：索引扫描条目

totalDocsExamined：文档扫描条目

对于一个查询，我们最理想的状态是：

nReturned=totalKeysExamined & totalDocsExamined=0：仅仅使用到了index，无需文档扫描

或

nReturned=totalKeysExamined=totalDocsExamined：正常index利用，无多余index扫描与文档扫描。

Stage

那么又是什么影响到了totalKeysExamined和totalDocsExamined？是stage的类型。类型列举如下：

COLLSCAN：全表扫描

IXSCAN：索引扫描

FETCH：根据索引去检索指定document

SHARD_MERGE：将各个分片返回数据进行merge

SORT：表明在内存中进行了排序

LIMIT：使用limit限制返回数

SKIP：使用skip进行跳过

IDHACK：针对_id进行查询

SHARDING_FILTER：通过mongos对分片数据进行查询

COUNT：利用db.coll.explain().count()之类进行count运算

COUNTSCAN：count不使用Index进行count时的stage返回

COUNT_SCAN：count使用了Index进行count时的stage返回

SUBPLA：未使用到索引的$or查询的stage返回

TEXT：使用全文索引进行查询时候的stage返回

PROJECTION：限定返回字段时候stage的返回

不希望看到包含如下的stage：

COLLSCAN(全表扫描)

SORT(使用sort但是无index)

不合理的SKIP

SUBPLA(未用到index的$or)

COUNTSCAN(不使用index进行count)

参考文章

MongoDB执行计划学习整理_LOUISLIAOXH的专栏-CSDN博客

mongodb .explain(‘executionStats’) 查询性能分析(转)

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有

0%