天天看点
返回

MongoDB索引-查询优化器索引概述索引的创建索引的选择总结

索引概述

介绍查询优化器首先要从索引开始。索引在计算机系统中应用非常广泛，是提高查询效率的常用手段。如果没有索引，MongoDB必须遍历集合中所有文档才能找到匹配的结果；如果存在一个适当的索引可以限制MongoDB必须检查的文档数量。

在MongoDB中，索引是一种特殊的数据结构，以一种便于遍历的方式存储集合数据的部分信息。

常见的索引有几种组织模型，其中，B-Tree索引可以看做将键值映射到有序数组中的位置；Hash索引将键值映射到无序数组中的位置。MongoDB默认采用B-Tree组织索引文件，在2.4版本后也允许建立Hash索引。

索引的创建

MongoDB索引是在集合上创建的，通过ensureIndex方法可以方便的设置索引。MongoDB集合可以创建多个索引。恰当的索引可以显著提高查询效率，但是当数据发生变动时，不仅需要修改更新文档，还要更新集合上的索引，这无疑会导致写操作要花费更多的时间。因此，MongoDB限制每个集合最多可以有64个索引，当然，只要设计合理，这个上限也是足够的。

我们用《MongoDB 权威指南》中的例子做一下修改，假设用MongoDB存储百万级用户数据，包括姓名(name), 性别(sex), 年龄(age)，电话(tel)信息。为了便于说明问题，这里只写四条数据：

> db.users.find()
{ "_id" : ObjectId("5a2f8e7bd24b2183ae3b9fab"), "name" : "Andy", "sex" : "male", "age" : , "tel" : "1300000001" }
{ "_id" : ObjectId("5a2f97c7eb221206e13c7c3f"), "name" : "Bale", "sex" : "male", "age" : , "tel" : "1300000002" }
{ "_id" : ObjectId("5a2fa15beb221206e13c7c40"), "name" : "Cindy", "sex" : "female", "age" : , "tel" : "1300000003" }
{ "_id" : ObjectId("5a2fa1cbeb221206e13c7c41"), "name" : "Dany", "sex" : "male", "age" : , "tel" : "1300000004" }

我们创建三个索引：

> db.users.ensureIndex({"age": , "sex": });
{
    "createdCollectionAutomatically" : false,
    "numIndexesBefore" : ,
    "numIndexesAfter" : ,
    "ok" : 
}
> db.users.ensureIndex({"age": });
{
    "createdCollectionAutomatically" : false,
    "numIndexesBefore" : ,
    "numIndexesAfter" : ,
    "ok" : 
}
> db.users.ensureIndex({"sex": , "age": });
{
    "createdCollectionAutomatically" : false,
    "numIndexesBefore" : ,
    "numIndexesAfter" : ,
    "ok" : 
}

在创建集合时，MongoDB会默认在_id字段上创建一个唯一索引，并且不能删除。所以当我们创建第一个索引时numIndexesBefore值是1。需要注意的是，B-Tree索引是有序的，上面三个索引大致结构是：

# {"age": 1, "sex": 1}
[, male]      ->  ObjectId("5a2f8e7bd24b2183ae3b9fab")
[, female]    ->  ObjectId("5a2fa15beb221206e13c7c40")
[, male]      ->  ObjectId("5a2f97c7eb221206e13c7c3f")
[, male]      ->  ObjectId("5a2fa1cbeb221206e13c7c41")

# {"age": 1}
[]      ->  ObjectId("5a2f8e7bd24b2183ae3b9fab")
[]      ->  ObjectId("5a2fa15beb221206e13c7c40")
[]      ->  ObjectId("5a2f97c7eb221206e13c7c3f")
[]      ->  ObjectId("5a2fa1cbeb221206e13c7c41")

# {"sex": 1, "age": 1}
[female, ]    ->  ObjectId("5a2fa15beb221206e13c7c40")
[male, ]      ->  ObjectId("5a2f8e7bd24b2183ae3b9fab")
[male, ]      ->  ObjectId("5a2f97c7eb221206e13c7c3f")
[male, ]      ->  ObjectId("5a2fa1cbeb221206e13c7c41")

索引的选择

MongoDB一个集合可以创建多个索引，查询优化器为索引创建查询计划，将选择索引转换为选择查询计划或者说选择查询计划对应的游标。

由于最近版本中几乎看不到优化器的概念，我们从较早的版本中开始介绍，以MongoDB-2.4.14为例，具体的选择过程可以分为三个阶段：首先根据查询模式（Query pattern）判断是否存在CachedPlan，如果存在直接选择，这里查询模式是除了数值外其他查询条件完全相同；其次，如果没有缓存记录，查询优化器创建新查询计划并标记类型，如果类型为Optimal Plan则直接执行该Plan；最后，如果不存在Optimal Plan，MongoDB会并发尝试可能的Helpful Plan以及不使用索引的基础查询。查询优化器会对比选择表现最好的查询计划继续执行，并将查询模式与最终查询计划的映射写入CachedPlan。

Optimal Plan

Optimal Plan的索引首先应该包含所有查询的过滤字段和排序字段，其次，字段在索引中的顺序是范围过滤和排序字段位于相等字段之后。有多个Optimal Plan时，会执行第一个。

Helpful Plan

不存在Optimal Plan时，查询优化器会并发执行所有Helpful查询计划。最早得到101个结果的查询计划会被选中继续执行，并将该查询计划暂存。其他查询计划会被中止。

下面列举几个例子，为了便于说明，我们将集合文档数扩大到1000000：

> var names = ["Andy", "Bale", "Cindy", "Dany", "Emmy", "Ford", "Gill"]
> var sexs = ["male", "female"]
> for (i=; i<; i++) {
    db.users.insert(
        {"name": names[Math.floor(Math.random()*)],
         "sex": sexs[Math.floor(Math.random()*)],
         "age": Math.floor(Math.random()*),
         "tel": +i
        } 
    ); 
}

首先查询age为18的所有记录，这里只截取部分输出信息：

> db.users.find({"age": }).explain({"verbose": true})
{
    "cursor" : "BtreeCursor age_1_sex_1",
    "isMultiKey" : false,
    "n" : ,
    "nscannedObjects" : ,
    "nscanned" : ,
    "millis" : ,
    "allPlans" : [
        {
            "cursor" : "BtreeCursor age_1_sex_1",
            "n" : ,
            "nscannedObjects" : ,
            "nscanned" : ,
        }
    ],
}

根据定义“age_1_sex_1”和“age_1”对应的查询计划都是Optimal Plan，这里选取了第一个便不再查找其他Plan，所以allPlans也只有“age_1_sex_1”一个。

下面第二次查询age为18的记录，同样截取部分输出：

> db.users.find({"age": }).explain({"verbose": true})
{
    "cursor" : "BtreeCursor age_1_sex_1",
    "isMultiKey" : false,
    "n" : ,
    "nscannedObjects" : ,
    "nscanned" : ,
    "millis" : ,
    "allPlans" : [
        {
            "cursor" : "BtreeCursor age_1_sex_1",
            "n" : ,
            "nscannedObjects" : ,
            "nscanned" : ,
        }
    ],
    "oldPlan" : {
        "cursor" : "BtreeCursor age_1_sex_1",
    },
}

与第一次不同，这里多了oldPlan。注意：

- 根据查询模式查找缓存查询计划，此时如果查找age为20只有值不同，同样会命中缓存。

- 由于指定了explain()，本次查询并没有直接使用缓存计划而是需要重新评估。

缓存的查询计划在以下条件下会清空并重新评估：

- 集合收到1000次写操作

- 执行reindex

- 添加或删除索引

- mongod进程重启

- 查询时指定explain()

第三个例子，我们查询name为Andy，age为18的记录：

> db.users.find({"age": , "name": "Andy"}).explain({"verbose": true})
{
    "cursor" : "BtreeCursor age_1",
    "isMultiKey" : false,
    "n" : ,
    "nscannedObjects" : ,
    "nscanned" : ,
    "millis" : ,
    "allPlans" : [
        {
            "cursor" : "BtreeCursor age_1",
            "n" : ,
            "nscannedObjects" : ,
            "nscanned" : ,
        },
        {
            "cursor" : "BtreeCursor age_1_sex_1",
            "n" : ,
            "nscannedObjects" : ,
            "nscanned" : ,
        },
        {
            "cursor" : "BasicCursor",
            "n" : ,
            "nscannedObjects" : ,
            "nscanned" : ,

        }
    ],
}

此次查询没有最优索引，两个索引“age_1_sex_1”和“age_1”对查询有帮助，连同基础查询总共创建三个查询计划。

评估候选查询计划会在以下情况之一发生时结束：

- 获取到所有查询结果；

- 最先得到101个查询结果（enoughCumulativeMatchesToChooseAPlan）

上面例子中，“age_1”最先返回101个查询结果，对应的查询计划执行到最后，其他查询计划被中止。

在MongoDB较新的版本中(以3.2.10为例)，查询优化器做了很大的改变。对于每个查询，系统首先在查询计划缓存中匹配相同查询信息(Query Shape)选择查询计划；如果没有命中缓存，查询计划生成器会评估所有候选查询计划，选择一个最优计划(Winning Plan)，并将最有计划写入缓存。

当缓存命中时，系统会重新评估该缓存计划，作出是否合格的判定，并根据判定结果保留或清除缓存计划。

下面是3.2.10版本的一次查询：

replset:PRIMARY> db.users.find({"age": , "sex": "male"}).explain("queryPlanner")
{
    "queryPlanner" : {
        "namespace" : "date.users",
        "indexFilterSet" : false,
        "winningPlan" : {
            "stage" : "FETCH",
            "inputStage" : {
                "indexName" : "sex_1_age_1",
            }
        },
        "rejectedPlans" : [
            {
                "inputStage" : {
                    "indexName" : "age_1",
                }
            },
            {
                "inputStage" : {
                    "indexName" : "age_1_sex_1",
                }
            }
        ]
    },
}

两个版本最主要的区别就是新版本取消了直接通过规则选择Optimal Plan的逻辑，按照以前的匹配规则，有“sex_1_age_1”这样的Optimal Plan不会再执行其他Optimal Plan和Helpfun Plan。取消Optimal Pan是因为往往Optimal Plan并不是最优的。下面是MongoDB-2.4.14的两个例子，同样只截取部分信息说明：

> db.users.find({"age": }, {"age": , "sex": , "_id": }).explain("verbose")
{
    "cursor" : "BtreeCursor age_1",
    "n" : ,
    "nscannedObjects" : ,
    "nscanned" : ,
    "indexOnly" : false,
    "millis" : ,
    "allPlans" : [
        {
            "cursor" : "BtreeCursor age_1",
            "n" : ,
            "nscannedObjects" : ,
            "nscanned" : ,
        }
    ],
}
> db.users.find({"age": }, {"age": , "sex": , "_id": }).hint("age_1_sex_1").explain("verbose")
{
    "cursor" : "BtreeCursor age_1_sex_1",
    "n" : ,
    "nscannedObjects" : ,
    "indexOnly" : true,
    "millis" : ,
    "allPlans" : [
        {
            "cursor" : "BtreeCursor age_1_sex_1",
            "n" : ,
            "nscannedObjects" : ,
            "nscanned" : ,
        }
    ],
}

上面的两次查询中，第一次查询“age_1”首先匹配到Optimal Plan并执行到最后，用时755毫秒，“age_1_sex_1”虽然同样是Optimal Plan，但是索引的顺序排在“age_1”之后，所以没有被选中。第二次查询中通过hint显式指定“age_1_sex_1”，通过该索引查询是“indexOnly”，不需要扫描文档就可以完成查询，所以效率更高，用时只有27毫秒。

另外，查询优化器还有一个变化，匹配缓存计划由Query Pattern变为Query Shape。官网上对二者的定义分别是：

- Query pattern refers to query select conditions that differ only in the values.

- A query shape consists of a combination of query, sort, and projection specifications.

Query Pattern 关注的是Fileds，Range和Sort，而Query Shape增加了Projection。

总结

查询优化器极大提升了查询性能，随着版本的升级，虽然最新的代码中已经很难找到“optimizer”的字段，但是逻辑仍然保留并且变得更加完善。

目前，查询优化器并不能保证每次查询都是最优的，无论是OptimalPlan 还是WinningPlan都是相对的，配合hint，index filter会使查询优化器更精准。

查询优化器是一次MongoDB查询的一个重要环节，深入了解可以帮助我们更合理的设计索引，更高效的使用MongoDB。

分布式系统 mongodb 索引 查询优化
上一篇: MongoDB索引说明及慢查询优化索引种类索引语法慢查询优化索引优化实战索引建议
下一篇: python mongodb查询速度优化_python实战计划－对mongodb进行查询

继续阅读