MongoDB查询索引分析
原创
背景
最近几年，nosql数据库发展迅猛，mongo无疑是最闪耀的那颗明星；以前我们部门的系统，用到数据库时基本上mysql是标配；现在越来越多的项目都开始选择mongo（无论自己搭建还是使用sa的ocean）；无论是mysql还是mongo，数据库是一个系统最容易出现问题、瓶颈的地方。
mysql出现问题时，相信大家都有一套完善的调试、调优方法，从最基础的查看slow log,query log到mysql explain查询索引分析等；而由于在mongo方面的技术积累没有mysql那么多，出现性能问题时，往往需要去花很大的精力进行调优。
索引
mongo中索引跟mysql中索引同样重要，没有索引，每次查找都需要遍历全表。
mongo的索引类型包括如下几种：
- single filed索引：最基本的索引类型，加在单个filed上，可以指定升降序，默认_id列会自动加上该索引
- Compound Index：复合索引加在多个field上，每一个字段都可以指定升降序；复合索引的顺序比较重要，它决定了该索引操作是否支持排序
- Multikey Index：如果给array类型的field加索引，mongo会自动创建一个multikey index
- Geospatial Index：
- Text Indexes: 一个集合最多只能够创建一个文本索引，文本索引加在string类型的列上
- Hashed Index
索引的一些特征：
- unique index：指定为唯一索引
- Partial Index：索引只会加到特定条件的document上，用户可以指定过滤条件
- Sparse Index：索引会跳过所有不包含被索引键的文档。这个索引之所以称为 “稀疏” 是因为它并不包括集合中的所有文档
- TTL Index：通过TTL索引，mongo会在过一段时间以后自动删除集合中的文档
mongo explain
与mysql相同，mongo也可以通过使用explain命令来查看mongo的执行情况，不同的是mongo的explain输出要复杂的多，mongo3.0版本对于explain做了很大的调整，本文只讨论3.0以后版本的explain情况。
包括count, distinct, group, find, findAndModify, delete,update等操作均可以执行explain。
explain有三种执行模式：
- queryPlanner mode: mongo 通过运行查询优化器选出winning plan
- executionStats Mode: 除了获取winning plan，mongo还会去真正的执行该plan，然后返回执行时的一些统计信息；该模式比较耗时（注意：对于写操作，mongo虽然会去执行这些winning plan，但是不会将这些修改应用到该database上）
- allPlansExecution Mode:返回更多的信息,默认模式
shell环境下可以通过db.collection.explain()、cursor.explain()、db.runCommand()三种方法来执行explain，pymongo可以通过db.command、cursor.explain()来获取explain的结果。
注意：aggrgate仅仅会在queryplanner模式下运行explain
##explain结果分析
一个典型的explain结果可能如下所示：
{ "queryPlanner" : { "plannerVersion" : 1, "namespace" : "game_db.game_user", "indexFilterSet" : false, "parsedQuery" : { "w" : { "$eq" : 1 } }, "winningPlan" : { "stage" : "FETCH", "inputStage" : { "stage" : "IXSCAN", "keyPattern" : { "w" : 1, "n" : 1 }, "indexName" : "w_1_n_1", "isMultiKey" : false, "direction" : "forward", "indexBounds" : { "w" : [ "[1.0, 1.0]" ], "n" : [ "[MinKey, MaxKey]" ] } } }, "rejectedPlans" : [ { "stage" : "FETCH", "inputStage" : { "stage" : "IXSCAN", "keyPattern" : { "w" : 1, "v" : 1 }, "indexName" : "w_1_v_1", "isMultiKey" : false, "direction" : "forward", "indexBounds" : { "w" : [ "[1.0, 1.0]" ], "v" : [ "[MinKey, MaxKey]" ] } } } ] },各字段的意义如下所示：
- namespace： 该query所查询的表
- winningPlan： 查询优化器针对该query返回的最优执行计划详细内容
- stage：非常重要的一个字段，后面分析
- inputStage： stage的child stage，此处是IXSCAN，表示进行的是index scanning
- keyPattern： 所扫描的index内容，此处是w:1与n:1
- indexName： 所选用的index
- isMultiKey： 是否是Multikey，此处返回是false，如果索引建立在array上，此处将是true
- direction： 此query的查询顺序，此处是forward，如果用了.sort({w:-1})将显示backward
- indexBounds： winningplan所扫描的索引范围，此处查询条件是w:1,使用的index是w与n的联合索引，故w是1.0,1.0而n没有指定在查询条件中，故是MinKey,MaxKey
- rejectedPlans：其他执行计划（非最优而被查询优化器reject的）的详细返回
如果在executionStats模式或者allPlansExecution模式下执行explain，其结果中还会包含executionStats信息：
"executionStats" : { "executionSuccess" : true, "nReturned" : 29861, "executionTimeMillis" : 23079, "totalKeysExamined" : 29861, "totalDocsExamined" : 29861, "executionStages" : { "stage" : "FETCH", "nReturned" : 29861, "executionTimeMillisEstimate" : 22685, "works" : 29862, "advanced" : 29861, "needTime" : 0, "needFetch" : 0, "saveState" : 946, "restoreState" : 946, "isEOF" : 1, "invalidates" : 0, "docsExamined" : 29861, "alreadyHasObj" : 0, "inputStage" : { "stage" : "IXSCAN", "nReturned" : 29861, "executionTimeMillisEstimate" : 70, "works" : 29862, "advanced" : 29861, "needTime" : 0, "needFetch" : 0, "saveState" : 946, "restoreState" : 946, "isEOF" : 1, "invalidates" : 0, "keyPattern" : { "w" : 1, "n" : 1 }, "indexName" : "w_1_n_1", "isMultiKey" : false, "direction" : "forward", "indexBounds" : { "w" : [ "[1.0, 1.0]" ], "n" : [ "[MinKey, MaxKey]" ] }, "keysExamined" : 29861, "dupsTested" : 0, "dupsDropped" : 0, "seenInvalidated" : 0, "matchTested" : 0 } } },其中重要字段含义如下：
- executionSuccess：是否执行成功
- nReturned：查询的返回条数
- executionTimeMillis：整体执行时间
- totalKeysExamined：索引扫描次数
- totalDocsExamined：document扫描次数
stage作为explain结果非常重要的一个字段，指明目前处于哪个阶段，常见的stage有：COLLSCAN(全表扫描), IXSCAN(索引扫描), FETCH(根据索引去检索指定document), SHARD_MERGE(将各个分片返回数据进行merge), SORT(在内存中进行排序), LIMIT(使用limit限制返回数), SKIP(使用skip进行跳过), TEXT(全文索引进行查询), PROJECTION(限定返回字段), IDHACK(针对_id进行查询)等等
对于普通查询，我们最希望看到的组合有这些：
- Fetch+IDHACK
- Fetch+ixscan
- Limit+（Fetch+ixscan）
- PROJECTION+ixscan
- SHARDING_FILTER+ixscan等undefined不希望看到包含如下的stage：undefinedCOLLSCAN（全表扫），SORT（使用sort但是无index），不合理的SKIP，SUBPLA（未用到index的$or）
查询分析器
无论哪种模式，explain的结果中都会有winning plan的信息，这些winning plan是通过mongo查询分析器获得的，查询分析器会缓存winning plan的信息，所以queryplanner模式的explain执行速度很快。
下面这幅图说明了查询分析器的执行逻辑：
详细信息见：https://docs.mongodb.com/manual/core/query-plans/
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
评论
登录后参与评论
推荐阅读
目录
腾讯云开发者
