MONOGO 索引

一、explain()，语句分析工具

MongoDB 3.0+的explain有三种模式，分别是：queryPlanner、executionStats、allPlansExecution。现实开发中，常用的是executionStats模式，主要分析这种模式。

> db.getCollection('customer').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
}

对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、查询集合索引

> db.getCollection('customer').getIndexes()

2、查看索引集合大小

> db.getCollection('customer').totalIndexSize()

3、创建普通索引

#1 表示升序，-1 表示降序
​> db.customer.ensureIndex({"tags":1}) 或者
​> db.customer.createIndex({"tags":1}) 或者
​> db.getCollection('customer').createIndex({"tags":1})

4、文档索引

> db.getCollection('customer').createIndex({"content.title":1, "content.judgementType":1}) 或者
> db.getCollection('customer').ensureIndex({"content.title":1, "content.judgementType":1}) 或者
> db.customer.createIndex({"content.title":1, "content.judgementType":1}) 或者
> db.customer.ensureIndex({"content.title":1, "content.judgementType":1})


#让创建索引的过程在后台运行
> db.getCollection('customer').createIndex({"content.title":1, "content.judgementType":1},{background:true})  

5、唯一索引

> db.customer.ensureIndex({"content.title":1, "content.judgementType":1},{unique: true})

6、强制使用索引

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

7、删除索引

#删除集合所有索引
db.getCollection('customer').dropIndexes()

#删除集合指定索引
db.getCollection('customer').dropIndex('索引名')

三、注意事项

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

2、OR查询
MongoDB在一次查询中只能使用一个索引（至少我现在用的2.6是这样的），如果你在{“x”:1}上有一个索引，在{“y”:1}上也有一个索引，在{“x”:1,“y”:1}上执行查询时，MongoDB只会使用其中一个索引，而不是两个一起使用。"$or"是一个例外，"$or"可以对每个字句都使用索引，因为"$or"实际上是执行两次查询然后将结果合并。
通常来说，使用or查询多次在合并结果，不如单次查询的效率高，对于单个字段，应该尽可能使用$in。

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

4、何时不应该使用索引
提取较小的子数据集时，索引非常有效（所以才有了分页）。也有一些查询不使用索引会更快。结果集在原集合中所占的比例越大，查询效率越慢。因为使用索引需要进行两次查找：一次查找索引条目，一次根据索引指针去查找相应的文档。而全表扫描只需要进行一次查询。在最坏的情况，使用索引进行查找次数会是全表扫描的两倍。效率会明显比全表扫描低。
可惜并没有一个严格的规则可以告诉我们，如果根据索引大小、文档大小来判断什么时候索引很有用，一般来说，如果查询需要返回集合内30%的文档（或者更多），那就应该测试全表扫描和走索引查询那个速度比较快。这个数字也会在2%~60%之间进行波动。

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