一、explain(),语句分析工具
MongoDB 3.0之后,explain的返回与使用方法与之前版本有了很大的变化,介于3.0之后的优秀特色和我们目前所使用给的是3.0.7版本,本文仅针对MongoDB 3.0+的explain进行讨论。3.0+的explain有三种模式,分别是:queryPlanner、executionStats、allPlansExecution。现实开发中,常用的是executionStats模式,主要分析这种模式。
给这个person集合创建age键的索引:db.person.createIndex({“age”:1})

db.getCollection('person').find({"age":{"$lte":2000}}).explain("executionStats")
{
    "queryPlanner" : {
        "plannerVersion" : 1,
        "namespace" : "personmap.person",
        "indexFilterSet" : false,
        "parsedQuery" : {
            "age" : {
                "$lte" : 2000.0
            }
        },
        "winningPlan" : {
            "stage" : "FETCH",
            "inputStage" : {
                "stage" : "IXSCAN",
                "keyPattern" : {
                    "age" : 1.0
                },
                "indexName" : "age_1",
                "isMultiKey" : false,
                "direction" : "forward",
                "indexBounds" : {
                    "age" : [ 
                        "[-1.#INF, 2000.0]"
                    ]
                }
            }
        },
        "rejectedPlans" : []
    },
    "executionStats" : {
        "executionSuccess" : true,
        "nReturned" : 2001,
        "executionTimeMillis" : 143,
        "totalKeysExamined" : 2001,
        "totalDocsExamined" : 2001,
        "executionStages" : {
            "stage" : "FETCH",
            "nReturned" : 2001,
            "executionTimeMillisEstimate" : 0,
            "works" : 2002,
            "advanced" : 2001,
            "needTime" : 0,
            "needFetch" : 0,
            "saveState" : 16,
            "restoreState" : 16,
            "isEOF" : 1,
            "invalidates" : 0,
            "docsExamined" : 2001,
            "alreadyHasObj" : 0,
            "inputStage" : {
                "stage" : "IXSCAN",
                "nReturned" : 2001,
                "executionTimeMillisEstimate" : 0,
                "works" : 2002,
                "advanced" : 2001,
                "needTime" : 0,
                "needFetch" : 0,
                "saveState" : 16,
                "restoreState" : 16,
                "isEOF" : 1,
                "invalidates" : 0,
                "keyPattern" : {
                    "age" : 1.0
                },
                "indexName" : "age_1",
                "isMultiKey" : false,
                "direction" : "forward",
                "indexBounds" : {
                    "age" : [ 
                        "[-1.#INF, 2000.0]"
                    ]
                },
                "keysExamined" : 2001,
                "dupsTested" : 0,
                "dupsDropped" : 0,
                "seenInvalidated" : 0,
                "matchTested" : 0
            }
        }
    },
    "serverInfo" : {
        "host" : "qinxiongzhou",
        "port" : 27017,
        "version" : "3.0.7",
        "gitVersion" : "6ce7cbe8c6b899552dadd907604559806aa2e9bd"
    },
    "ok" : 1.0
}

db.getCollection(‘person’).find({“age”:{"$lte":2000}}).explain(“executionStats”)

对queryPlanner分析

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

最为直观explain返回值是executionTimeMillis值,指的是我们这条语句的执行时间,这个值当然是希望越少越好。

其中有3个executionTimeMillis,分别是:

executionStats.executionTimeMillis

该query的整体查询时间。

executionStats.executionStages.executionTimeMillisEstimate

该查询根据index去检索document获得2001条数据的时间。

executionStats.executionStages.inputStage.executionTimeMillisEstimate

该查询扫描2001行index所用时间。

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

这个主要讨论3个返回项,nReturned、totalKeysExamined、totalDocsExamined,分别代表该条查询返回的条目、索引扫描条目、文档扫描条目。

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

对于一个查询,我们最理想的状态是:

nReturned=totalKeysExamined=totalDocsExamined

第三层,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的组合(查询的时候尽可能用上索引):

Fetch+IDHACK

Fetch+ixscan

Limit+(Fetch+ixscan)

PROJECTION+ixscan

SHARDING_FITER+ixscan

COUNT_SCAN

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

COLLSCAN(全表扫描),SORT(使用sort但是无index),不合理的SKIP,SUBPLA(未用到index的$or),COUNTSCAN(不使用index进行count)

二、建索引
1.基础索引

在字段age 上创建索引,1(升序);-1(降序):
db.users.ensureIndex({age:1})
_id 是创建表的时候自动创建的索引,此索引是不能够删除的。当系统已有大量数据时,创建索引就是个非常耗时的活,我们可以在后台执行,只需指定“backgroud:true”即可。
db.t3.ensureIndex({age:1} , {background:true})

2.文档索引

索引可以任何类型的字段,甚至文档:
db.factories.insert( { name: “wwl”, addr: { city: “Beijing”, state: “BJ” } } );
//在addr 列上创建索引
db.factories.ensureIndex( { addr : 1 } );
//下面这个查询将会用到我们刚刚建立的索引
db.factories.find( { addr: { city: “Beijing”, state: “BJ” } } );
//但是下面这个查询将不会用到索引,因为查询的顺序跟索引建立的顺序不一样
db.factories.find( { addr: { state: “BJ” , city: “Beijing”} } );

3. 组合索引
跟其它数据库产品一样,MongoDB 也是有组合索引的,下面我们将在addr.city 和addr.state上建立组合索引。当创建组合索引时,字段后面的1 表示升序,-1 表示降序,是用1 还是用-1 主要是跟排序的时候或指定范围内查询 的时候有关的。

db.factories.ensureIndex( { “addr.city” : 1, “addr.state” : 1 } );
// 下面的查询都用到了这个索引
db.factories.find( { “addr.city” : “Beijing”, “addr.state” : “BJ” } );
db.factories.find( { “addr.city” : “Beijing” } );
db.factories.find().sort( { “addr.city” : 1, “addr.state” : 1 } );
db.factories.find().sort( { “addr.city” : 1 } )

4. 唯一索引
只需在ensureIndex 命令中指定”unique:true”即可创建唯一索引。例如,往表t4 中插入2 条记录:
db.t4.ensureIndex({firstname: 1, lastname: 1}, {unique: true});

5.强制使用索引
hint 命令可以强制使用某个索引。
db.t5.find({age:{$lt:30}}).hint({name:1, age:1}).explain()

6.删除索引
//删除t3 表中的所有索引
db.t3.dropIndexes()
//删除t4 表中的namez字段的索引
db.t4.dropIndex(“dpt_AirPt_Cd_itia_1_arrv_Airpt_Cd_itia_1_chainage_1”)
6.查询索引
db.t4.getIndexes()

三、其他优化
1、MongoDB中低效率的操作符
“where"和"where"和"exists”:这两个操作符,完全不能使用索引。
“ne":通常来说取反的效率比较低。“ne”:通常来说取反的效率比较低。"ne"查询可以使用索引,但并不是很有效。因为他必须查看所有的索引条目,而不是"ne"指定的条目,这个时候他就不得不扫描整个索引。 "ne"指定的条目,这个时候他就不得不扫描整个索引。"not”:有时候能够使用索引,但是他通常并不知道要如何使用索引。所以大多数情况"not"会退化为全表扫描。 "not"会退化为全表扫描。“nin”:这个操作符总是会全表扫描

2、OR查询
MongoDB在一次查询中只能使用一个索引(至少我现在用的2.6是这样的),如果你在{“x”:1}上有一个索引,在{“y”:1}上也有一个索引,在{“x”:1,“y”:1}上执行查询时,MongoDB只会使用其中一个索引,而不是两个一起使用。“or"是一个例外,"or"是一个例外,"or"可以对每个字句都使用索引,因为”$or"实际上是执行两次查询然后将结果合并。

 通常来说,使用or查询多次在合并结果,不如单次查询的效率高,对于单个字段,应该尽可能使用$in。

3、MongoDB的查询优化器
MongoDB的查询优化器与其他数据库的稍微不同。基本来说,如果一个索引能够精确匹配一个查询,那么查询优化器就会使用这个索引,如果不能精确匹配,可能会有几个索引都适合你的查询。那MongoDB是怎样选择的呢?答:MongoDB的查询计划会将多个索引并行的去执行,最早返回100个结果的就是胜者,其他查询计划都会被终止。

这个查询计划会被缓冲,接下来的这个查询都会使用他,下面几种情况会重新计划;
最初的计划评估之后集合发生了比较大的数据波动,查询优化器就会重新挑选可行的查询计划。
建立索引时。
每执行1000次查询之后,查询优化器就会重新评估查询计划

4、何时不应该使用索引
提取较小的子数据集时,索引非常有效(所以才有了分页)。也有一些查询不使用索引会更快。结果集在原集合中所占的比例越大,查询效率越慢。因为使用索引需要进行两次查找:一次查找索引条目,一次根据索引指针去查找相应的文档。而全表扫描只需要进行一次查询。在最坏的情况,使用索引进行查找次数会是全表扫描的两倍。效率会明显比全表扫描低。

可惜并没有一个严格的规则可以告诉我们,如果根据索引大小、文档大小来判断什么时候索引很有用,一般来说,如果查询需要返回集合内30%的文档(或者更多),那就应该测试全表扫描和走索引查询那个速度比较快。这个数字也会在2%~60%之间进行波动。

这个时候可以使用hint({"$natural":true})强制查询走全表扫描。