新浪博客

MongoDB执行计划分析详解

2016-09-20 14:20阅读：

http://blog.sina.cn/dpool/blog/u/1660520290

引子

MongoDB 3.0之后，explain的返回与使用方法与之前版本有了不少变化，介于3.0之后的优秀特色，本文仅针对MongoDB 3.0+的explain进行讨论。
现版本explain有三种模式，分别如下：
  • queryPlanner
  • executionStats
  • allPlansExecution
  • ​

一 queryPlanner

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

queryPlanner模式的各个返回意义

explain.queryPlanner
queryPlanner的返回。
explain.queryPlanner.namespace
顾名思义，该值返回的是该query所查询的表。
explain.queryPlanner.indexFilterSet
针对该query是否有indexfilter（会在后文进行详细解释）。
explain.queryPlanner.winningPlan
查询优化器针对该query所返回的最优执行计划的详细内容。
explain.queryPlanner.winningPlan.stag
e
最优执行计划的stage，这里返回是FETCH，可以理解为通过返回的index位置去检索具体的文档（stage有数个模式，将在后文中进行详解）。
explain.queryPlanner.winningPlan.inputStage
explain.queryPlanner.winningPlan.stage的child stage，此处是IXSCAN，表示进行的是index scanning。
explain.queryPlanner.winningPlan.keyPattern
所扫描的index内容，此处是w:1与n:1。
explain.queryPlanner.winningPlan.indexName
winning plan所选用的index。
explain.queryPlanner.winningPlan.isMultiKey
是否是Multikey，此处返回是false，如果索引建立在array上，此处将是true。
explain.queryPlanner.winningPlan.direction
此query的查询顺序，此处是forward，如果用了.sort({w:-1})将显示backward。
explain.queryPlanner.winningPlan.indexBounds
winningplan所扫描的索引范围，此处查询条件是w:1,使用的index是w与n的联合索引，故w是[1.0,1.0]而n没有指定在查询条件中，故是[MinKey,MaxKey]。
explain.queryPlanner.rejectedPlans
其他执行计划（非最优而被查询优化器reject的）的详细返回，其中具体信息与winningPlan的返回中意义相同，故不在此赘述。

二 executionStats

executionStats的返回中多了如下：
(因新浪博客对代码支持的不够好，所以这里省去，如果有需要可以给我留言联系我，我发完整日志给你)
executionStats模式中，我们主要需要注意的返回有如下几个
executionStats.executionSuccess
是否执行成功
executionStats.nReturned
查询的返回条数
executionStats.executionTimeMillis
整体执行时间
executionStats.totalKeysExamined
索引扫描次数
executionStats.totalDocsExamined
document扫描次数
以上几个非常好理解，我们就不在这里详述，后文的案例中会有分析。
executionStats.executionStages.stage
这里是FETCH去扫描对于documents
executionStats.executionStages.nReturned
由于是FETCH，所以这里该值与executionStats.nReturned一致
executionStats.executionStages.docsExamined
与executionStats.totalDocsExamined一致
executionStats.inputStage中的与上述理解方式相同
还有一些文档中没有描述的返回如：
“works” : 29862,
“advanced” : 29861,
“isEOF” : 1,
这些值都会在explan之初初始化。
以works为例，查看源码中发现，每次操作会加1，且会把执行时间记录在executionTimeMillis中
而在查询结束EOF，works又会加1，advanced不加。故正常的返回works会比nReturned多1，这时候isEOF为true（1），advanced的返回值在命中的时候+1，在skip,eof的时候不会增加。

三 Stage详解

Stage的意义如explain.queryPlanner.winningPlan.stage和explain.queryPlanner.winningPlan.inputStage等。
文档中仅有如下几类介绍：
  • COLLSCAN 全表扫描
  • IXSCAN 索引扫描
  • FETCH 根据索引去检索指定document
  • SHARD_MERGE 将各个分片返回数据进行merge
但是根据源码中的信息，个人还总结了文档中没有的如下几类(常用如下，由于是通过源码查找，可能有所遗漏)
  • SORT 表明在内存中进行了排序（与老版本的scanAndOrder:true一致）
  • 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的返回

三 对Explain返回逐层分析

第一层，executionTimeMillis

。
首先，最为直观explain返回值是executionTimeMillis值，指的是我们这条语句的执行时间，这个值当然是希望越少越好。
且executionTimeMillis 与stage有同样的层数，即：
'executionStats' : {
'executionSuccess' : true,
'nReturned' : 29861,
'executionTimeMillis' : 66948,
'totalKeysExamined' : 29861,
'totalDocsExamined' : 29861,
'executionStages' : {
'stage' : 'FETCH',
'nReturned' : 29861,
'executionTimeMillisEstimate' : 66244,
'works' : 29862,
'advanced' : 29861,
'needTime' : 0,
'needFetch' : 0,
'saveState' : 2934,
'restoreState' : 2934,
'isEOF' : 1,
'invalidates' : 0,
'docsExamined' : 29861,
'alreadyHasObj' : 0,
'inputStage' : {
'stage' : 'IXSCAN',
'nReturned' : 29861,
'executionTimeMillisEstimate' : 290,
'works' : 29862,
'advanced' : 29861,
'needTime' : 0,
'needFetch' : 0,
'saveState' : 2934,
'restoreState' : 2934,
...
其中有3个executionTimeMillis，分别是
  • executionStats.executionTimeMillis
该query的整体查询时间
  • executionStats.executionStages.executionTimeMillis
该查询根据index去检索document获取29861条具体数据的时间
  • executionStats.executionStages.inputStage.executionTimeMillis
该查询扫描29861行index所用时间
这三个值我们都希望越少越好，那么是什么影响这这三个返回值呢？
抛开硬件因素等不谈，我们来进行下一层的剥离。

第二层，index与document扫描数与查询返回条目数

这里主要谈3个返回项，nReturned，totalKeysExamined与totalDocsExamined，分别代表该条查询返回的条目、索引扫描条目和文档扫描条目。
很好理解，这些都直观的影响到executionTimeMillis，我们需要扫描的越少速度越快。
对于一个查询， 我们最理想的状态是
nReturned=totalKeysExamined & totalDocsExamined=0
（cover index，仅仅使用到了index，无需文档扫描，这是最理想状态。）
或者
nReturned=totalKeysExamined=totalDocsExamined(需要具体情况具体分析)
（正常index利用，无多余index扫描与文档扫描。）
如果有sort的时候，为了使得sort不在内存中进行，我们可以在保证nReturned=totalDocsExamined 的基础上，totalKeysExamined可以大于totalDocsExamined与nReturned，因为量级较大的时候内存排序非常消耗性能。
后面我们会针对例子来进行分析。

第三层，Stage状态分析

那么又是什么影响到了totalKeysExamined与totalDocsExamined呢？就是Stage的类型，Stage的具体含义在上文中有提及，如果认真看的同学就不难理解为何Stage会影响到totalKeysExamined 和totalDocsExamined从而影响executionTimeMillis了。
此前有讲解过stage的类型，这里再简单列举下（具体意义请看上文）
  • COLLSCAN
  • IXSCAN
  • FETCH
  • SHARD_MERGE
  • SORT
  • LIMIT
  • SKIP
  • IDHACK
  • SHARDING_FILTER
  • COUNT
  • COUNTSCAN
  • COUNT_SCAN
  • SUBPLA
  • TEXT
  • PROJECTION
对于普通查询，我们最希望看到的组合有这些：
  • Fetch+IDHACK
  • Fetch+ixscan
  • Limit+（Fetch+ixscan）
  • PROJECTION+ixscan
  • SHARDING_FILTER+ixscan
等
不希望看到包含如下的stage：
  • COLLSCAN（全表扫），
  • SORT（使用sort但是无index），
  • 不合理的SKIP，
  • SUBPLA（未用到index的$or）
对于count查询，希望看到的有：
  • COUNT_SCAN
不希望看到的有:
  • COUNTSCAN
  • ​
executionStages.Stage为Sort，在内存中进行排序了，这个在生产环境中尤其是在数据量较大的时候，是非常消耗性能的，这个千万不能忽视了，我们需要改进这个点。

我的更多文章

下载客户端阅读体验更佳

APP专享