MongoDB学习报告（二）

2016-07-24 本文已影响193人 Mr_Lance

概述

MongoDB索引管理
MongoDB查询优化

MongoDB索引管理

单键索引中的每一项都应该对应被索引文档里面的一个值
复合索引就是每一项都由多个键组合而成的索引。复合索引里的键的顺序是很重要。
每一个索引都会对维护带来成本，如果一个集合上有10个索引，每次写操作都要更新10个索引，所以要保证没有多余的索引
使用索引起码要保证索引都放到内存中，理想状态是索引和使用中的集合都放到内存里面。
一个集合可以创建多个索引，但是只会使用最合适的一个，$or例外（待明确）

索引管理

创建索引：索引的创建方法3.0之前使用ensureInde()方法，3.0之后使用的是createIndex()，1为指定按升序创建索引，如果你想按降序来创建索引指定为-1。如果文档中嵌套文档，可以建立子文档的索引。对应大数据集合，构建索引可能会需要几个小时或者几天，background项允许索引创建在后台执行。

#单键索引，用户表为例。
db.user.createIndex({name: 1});
#复合索引
db.user.createIndex({name: 1,age: -1});
#输出显示，索引创建成功
{
    "createdCollectionAutomatically" : false,
    "numIndexesBefore" : 1,
    "numIndexesAfter" : 2,
    "ok" : 1
}
#子文档索引，假如用户的地址address是一个文档，可以以address的city值建立索引
db.user.createIndex({address.city: 1});
#后台执行索引创建
db.user.createIndex({name: 1,age: -1},{background: true});

查询索引：

 db.user.getIndexes();
#结果
[
    {
        "v" : 1,
        "key" : {
            "_id" : 1
        },
        "name" : "_id_",
        "ns" : "test.user"
    },
    {
        "v" : 1,
        "unique" : true,
        "key" : {
            "name" : 1
        },
        "name" : "name_1",
        "ns" : "test.user"
    }
]

删除索引：dropIndex()删除指定索引，dropIndexes()删除全部索引，_id除外。

#删除索引名为name_1的索引
db.user.dropIndex("name_1");
#删除所有索引
db.user.dropIndexes();

唯一索引：创建方式，设置unique。唯一索引通常插入数据之前创建，提前创建避免数据重复导致唯一索引建立失败，如果数据不重要，可以使用dropDups选项告诉数据库自动删除重复文档。

#设置name键唯一索引,
db.user.createIndex({name: 1},{unique: true});
#设置唯一索引后插入重复数据会有一个错误提示
WriteResult({
    "nInserted" : 0,
    "writeError" : {
        "code" : 11000,
        "errmsg" : "E11000 duplicate key error collection: test.user index: name_1 dup key: { : \"lance\" }"
    }
})
#已有重复数据的集合创建索引
db.user.createIndex({name: 1},{unique: true,dropDups: true});

稀疏索引：索引默认都密集型的，就是说一个有索引的集合中，每一个文档都有对应的索引项，如果文档没有索引键，对应的索引也会有个null的值。例如上面的用户表中，有的用户没有age的键，假如创建一个age的索引，* db.user.find({age: null}) *查询也是可以使用到索引定位到对应的用户。但是有些情况下密集型索引并不适合，例如：

商城的产品集合都有个sku的唯一码，如果sku键有唯一索引，现在要插入多个没有sku的产品，那么第一次会成功，之后的都会失败，因为唯一索引里sku已经有了null的项。这种情况下就需要稀疏索引。

db.product.createIndex({sku: 1},{unique: true, sparse: true})

评论功能user_id键建立索引，但是允许匿名评论。这种情况下如果使用密集型，因为集合中大量的文档user_id的键不存在，索引就会拥有大量的null的项都会是null，这样会增加了索引的大小，更重要的是user_id为null的文档写操作的时候也会更新索引。极少或者不对匿名用户进行查询的情况下应该使用稀疏索引。

db.commons.createIndex({user_id}: 1},{sparse: true})

多键索引：MongoDB允许索引中的多个条目指向同一个文档，多键索引默认处于激活状态，只要被索引键为数组每个数组值都会在索引中有自己的位置。例如文章集合中每篇文章可能有多个标签，用数组tags记录。假如在tags键上建立索引，则tags每个数组值都会在索引中。

{
    "title":文章列表,
    "tags":["mysql", "nosql", "nginx"]    
}

MongoDB查询优化

慢查询：开启可以有效的识别语句消耗是否超过预期。Mongodb开启慢查询使用的是Profiling工具，该工具在运行的实例上收集有关MongoDB的写操作，游标，数据库命令等，可以在数据库级别开启该工具，也可以在实例级别开启。该工具会把收集到的所有都写入到system.profile固定集合,集合大小是固定的，超过最大默认值时新记录覆盖旧记录。

可以修改配置文件默认开启慢查询

#打开配置文件，添加慢查询配置。profile是开启的级别，0是关闭；1是收集慢查询数据，开启慢查询；2是记录所有的操作。slowms慢查询时间，单位毫秒，默认100ms
profile=1
slowms=200

直接在对应的数据库执行开启命令

#开启慢查询，记录执行时间超过200ms的查询语句。如果不填则默认100ms。
db.setProfilingLeve(1,200);
#输出效果
{ "was" : 0, "slowms" : 200, "ok" : 1 } 
#可以查询当前数据开启的profile
db.getProfilingLeve();

查看记录，更多信息见：官方文档

#查询用户表
db.user.find();
#查看慢system.profile集合,pretty格式化输出
db.system.profile.find().pretty()
{
    "op" : "query", #操作类型，有insert、query、update、remove、getmore、command   
    "ns" : "test.user", #操作的集合
    "query" : {  #查询语句
        "find" : "user",
        "filter" : {
            
        }
    },
    "keysExamined" : 0,#索引扫描条目，对应3.2版本之前的nscanned
    "docsExamined" : 2, #文档扫描条目，对应3.2版本之前的nscannedObjects
    "cursorExhausted" : true,
    "keyUpdates" : 0,#在操作里更新的改变 index 的数量。改变一个索引值会消耗一点性能，因为数据库必须移掉老的值并插入新的值到B-tree索引中。
    "writeConflicts" : 0,
    "numYield" : 0,
    "locks" : {  #锁信息，R：全局读锁；W：全局写锁；r：特定数据库的读锁；w：特定数据库的写锁
        ......
    },
    "nreturned" : 2,  #返回的记录数。如果用limit(n)命令将返回n个文档，ntoreturn值是n
    "responseLength" : 314,  #结果字节长度，一个大的 responseLength会影响性能.
    "protocol" : "op_command",
    "millis" : 106,    #消耗的时间（毫秒）
    "execStats" : {
        ......
    },
    "ts" : ISODate("2016-07-22T07:32:46.289Z"),#语句执行的时间
    "client" : "127.0.0.1",#链接ip或则主机
    "allUsers" : [
        {
            "user" : "lance",
            "db" : "admin"
        }
    ],
    "user" : "lance@admin" #用户
}

#执行带索引的搜索，"millis" : 13，keysExamined和docsExamined都变成1。
db.user.find({name:"lance"})

分析慢查询：
** 使用并了解EXPLAIN() **

3.0版本之前，可以直接用explain()函数
3.0版本后explain有所改动，分成三种模式，默认queryPlanner，executionStats，allPlansExecution
- queryPlanner查询计划的选择器，首先进行查询分析，最终选择一个winningPlan，是explain返回的默认层面。
- executionStats为执行统计层面，返回winningPlan的统计结果
- allPlansExecution为返回所有执行计划的统计，包括rejectedPlan

db.test.find({name:'lance'}).explain()
#结果
{
    "queryPlanner" : {
        "plannerVersion" : 1,
        "namespace" : "test.test", #该值返回的是该query所查询的表
        "indexFilterSet" : false, #该query是否有indexfilter
        "parsedQuery" : {
            "name" : {
                "$eq" : "lance"
            }
        },
        "winningPlan" : {  #查询优化器针对该query所返回的最优执行计划的详细内容
            "stage" : "FETCH",#最优执行计划的stage，这里返回是FETCH，可以理解为通过返回的index位置去检索具体的文档(下面有不同类型的介绍)
            "inputStage" : { #用来描述子stage，并且为其父stage提供文档和索引关键字。
                "stage" : "IXSCAN", 
                "keyPattern" : {
                    "name" : 1  #所扫描的index内容
                },
                "indexName" : "name_1",
                "isMultiKey" : false, #是否是Multikey，此处返回是false，如果索引建立在array上，此处将是true
                ......
                "direction" : "forward", #此query的查询顺序，此处是forward，如果用了.sort({modify_time:-1})将显示backward
                "indexBounds" : { #所扫描的索引范围,如果没有制定范围就是[MaxKey, MinKey]，这主要是直接定位到mongodb的chunck中去查找数据，加快数据读取。
                    "name" : [
                        "[\"lance\", \"lance\"]"
                    ]
                }
            }
        },
        "rejectedPlans" : [ ] #其他执行计划（非最优而被查询优化器reject的）的详细返回
    },
    ......
}

db.test.find({name:'lance'}).explain('executionStats')
{
    "queryPlanner" : {
        ...... 
    },
    "executionStats" : {
        "executionSuccess" : true, #是否执行成功
        "nReturned" : 1, #满足查询条件的文档个数，即查询的返回条数
        "executionTimeMillis" : 0, #整体执行时间
        "totalKeysExamined" : 1, #索引整体扫描的文档个数
        "totalDocsExamined" : 1,#document扫描个数
        "executionStages" : {
            ......
        }
    },
    ......
}

** stage的类型的意义 **

COLLSCAN ：全表扫描
IXSCAN：索引扫描
FETCH:：根据索引去检索指定document
SHARD_MERGE：各个分片返回数据进行merge
SORT：表明在内存中进行了排序（与前期版本的scanAndOrder:true一致）
SORT_MERGE：表明在内存中进行了排序后再合并
LIMIT：使用limit限制返回数
SKIP：使用skip进行跳过
IDHACK：针对_id进行查询
SHARDING_FILTER：通过mongos对分片数据进行查询
COUNT：利用db.coll.count()之类进行count运算
COUNTSCAN：count不使用用Index进行count时的stage返回
COUNT_SCAN：count使用了Index进行count时的stage返回
SUBPLA：未使用到索引的$or查询的stage返回
TEXT：使用全文索引进行查询时候的stage返回

MongoDB学习报告（二）

概述

MongoDB索引管理

索引管理

MongoDB查询优化

猜你喜欢

热点阅读