Mongodb 3 查询优化（语句优化、建索引）

时间  2019-11-17
标签 mongodb 查询 优化 语句 索引 栏目 MongoDB 繁體版
原文   原文链接

1、explain()，语句分析工具git

MongoDB 3.0以后，explain的返回与使用方法与以前版本有了很大的变化，介于3.0以后的优秀特点和咱们目前所使用给的是3.0.7版本，本文仅针对MongoDB 3.0+的explain进行讨论。3.0+的explain有三种模式，分别是：queryPlanner、executionStats、allPlansExecution。现实开发中，经常使用的是executionStats模式，主要分析这种模式。mongodb

    给这个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是否有indexfilterspa

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

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

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

    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)

2、建索引

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()

 三、其余优化

一、MongoDB中低效率的操做符

"$where"和"$exists"：这两个操做符，彻底不能使用索引。

"$ne":一般来讲取反的效率比较低。"$ne"查询可使用索引，但并非颇有效。由于他必须查看全部的索引条目，而不是"$ne"指定的条目，这个时候他就不得不扫描整个索引。

"$not":有时候可以使用索引，可是他一般并不知道要如何使用索引。因此大多数状况"$not"会退化为全表扫描。

"$nin":这个操做符老是会全表扫描

二、OR查询

         MongoDB在一次查询中只能使用一个索引（至少我如今用的2.6是这样的），若是你在{"x":1}上有一个索引，在{"y":1}上也有一个索引，在{"x":1,"y":1}上执行查询时，MongoDB只会使用其中一个索引，而不是两个一块儿使用。"$or"是一个例外，"$or"能够对每一个字句都使用索引，由于"$or"其实是执行两次查询而后将结果合并。

         一般来讲，使用or查询屡次在合并结果，不如单次查询的效率高，对于单个字段，应该尽量使用$in。

三、MongoDB的查询优化器

        MongoDB的查询优化器与其余数据库的稍微不一样。基原本说，若是一个索引可以精确匹配一个查询，那么查询优化器就会使用这个索引，若是不能精确匹配，可能会有几个索引都适合你的查询。那MongoDB是怎样选择的呢？答：MongoDB的查询计划会将多个索引并行的去执行，最先返回100个结果的就是胜者，其余查询计划都会被终止。

      这个查询计划会被缓冲，接下来的这个查询都会使用他，下面几种状况会从新计划；

    1. 最初的计划评估以后集合发生了比较大的数据波动，查询优化器就会从新挑选可行的查询计划。
    2. 创建索引时。
    3. 每执行1000次查询以后，查询优化器就会从新评估查询计划

四、什么时候不该该使用索引

        提取较小的子数据集时，索引很是有效（因此才有了分页）。也有一些查询不使用索引会更快。结果集在原集合中所占的比例越大，查询效率越慢。由于使用索引须要进行两次查找：一次查找索引条目，一次根据索引指针去查找相应的文档。而全表扫描只须要进行一次查询。在最坏的状况，使用索引进行查找次数会是全表扫描的两倍。效率会明显比全表扫描低。

        惋惜并无一个严格的规则能够告诉咱们，若是根据索引大小、文档大小来判断何时索引颇有用，通常来讲，若是查询须要返回集合内30%的文档（或者更多），那就应该测试全表扫描和走索引查询那个速度比较快。这个数字也会在2%~60%之间进行波动。

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

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程