MongoDb（六）索引原理和命令

（一）索引基本介绍

索引是提高查询查询效率最有效的手段。索引是一种特殊的数据结构，索引以易于遍历的形式存储了数据的部分内容(Mongodb使用B-Tree(B树)存储数据，Mysql使用B+树)（如：一个特定的字段或一组字段值），索引会按一定规则对存储值进行排序，而且索引的存储位置在内存中，所在从索引中检索数据会非常快。如果没有索引，MongoDB必须扫描集合中的每一个文档，这种扫描的效率非常低，尤其是在数据量较大时。。比如mmapv1引擎里，位置信息是『文件id + 文件内offset 』，在wiredtiger存储引擎（一个KV存储引擎）里，位置信息是wiredtiger在存储文档时生成的一个key，通过这个key能访问到对应的文档；为方便介绍，统一用pos(position的缩写)来代表位置信息。

假设现在有个查询 db.person.find( {age: 18} ), 查询所有年龄为18岁的人，这时需要遍历所有的文档（『全表扫描』），根据位置信息读出文档，对比age字段是否为18。当然如果只有4个文档，全表扫描的开销并不大，但如果集合文档数量到百万、甚至千万上亿的时候，对集合进行全表扫描开销是非常大的，一个查询耗费数十秒甚至几分钟都有可能。

如果想加速 db.person.find( {age: 18} ），就可以考虑对person表的age字段建立索引。

// 按age字段创建升序索引    1为升序 -1为降序
db.person.createIndex( {age: 1} )

createIndex可接受参数：

createIndex接受参数示例：

建立索引后，MongoDB会额外存储一份按age字段升序排序的索引数据(注意：该字段索引中存的数据是这张表的所有数据，无论文档是否具有该索引字段)，索引结构类似如下，索引通常采用类似btree的结构持久化存储，以保证从索引里快速（O(logN)的时间复杂度）找出某个age值对应的位置信息，然后根据位置信息就能读取出对应的文档。

简单的说，索引就是将文档按照某个（或某些）字段顺序组织起来，以便能根据该字段高效的查询。有了索引，至少能优化如下场景的效率：

查询，比如查询年龄为18的所有人
更新/删除，将年龄为18的所有人的信息更新或删除，因为更新或删除时，需要根据条件先查询出所有符合条件的文档，所以本质上还是在优化查询
排序，将所有人的信息按年龄排序，如果没有索引，需要全表扫描文档，然后再对扫描的结果进行排序

众所周知，MongoDB默认会为插入的文档生成_id字段（如果应用本身没有指定该字段），_id是文档唯一的标识，为了保证能根据文档id快递查询文档，你在为其他字段创建索引时，MongoDB同时默认会为集合创建_id字段的索引。

mongo-9552:PRIMARY> db.person.getIndexes() // 查询集合的索引信息
[{"ns" : "test.person",  // 集合名"v" : 1,               // 索引版本"key" : {              // 索引的字段及排序方向"_id" : 1           // 根据_id字段升序索引},"name" : "_id_"        // 索引的名称}
]

索引特别注意1：

1：由于索引是存储在内存(RAM)中,你应该确保该索引的大小不超过内存的限制。如果索引的大小大于内存的限制，MongoDB会删除一些索引，这将导致性能下降。
2：索引不能被以下的查询使用：

正则表达式及非操作符，如 $nin, $not, 等。

算术运算符，如 $mod, 等。

$where 子句
所以，检测你的语句是否使用索引是一个好的习惯，可以用explain来查看。

3：最大范围：

集合中索引不能超过64个

索引名的长度不能超过128个字符

一个复合索引最多可以有31个字段

索引特别注意2：

1：每个索引占据一定的存储空间，在进行插入，更新和删除操作时也需要对索引进行操作。所以，如果你很少对集合进行读取操作，建议不使用索引。
2：mongoDB通常在一次查询里使用一个索引，所以多个字段的查询或者排序需要复合索引才能更加高效。
3：复合索引的顺序非常重要。
4：在生产环境构建索引往往开销很大,时间也不可以接受,在数据量庞大之前尽量进行查询优化和构建索引；
5：避免昂贵的查询，使用查询分析器记录那些开销很大的查询便于问题排查。
6：通过减少扫描文档数量来优化查询，使用explain对开销大的查询进行分析并优化；索引是用来查询小范围数据的，不适合使用索引的情况。
7:如果查询都是需要把表中所有数据展示，没有条件。这种加了索引反而降低查询效率，所有mongodb自动会不适用索引！

（二）索引类型

MongoDB支持多种类型的索引，包括单字段索引、复合索引、多key索引、文本索引等，每种类型的索引有不同的使用场合。

（1）单字段索引(针对一个字段)

db.person.createIndex( {age: 1} )  // 按age字段创建升序索引

上述语句针对age创建了单字段索引，其能加速对age字段的各种查询请求，是最常见的索引形式，MongoDB默认创建的id索引也是这种类型。
{age: 1} 代表升序索引，也可以通过{age: -1}来指定降序索引，对于单字段索引，升序/降序效果是一样的。对同一字段可以既创建升序索引又创建降序索引：

（2）复合索引(针对多个索引)

复合索引能满足的查询场景比单字段索引更丰富，不光能满足多个字段组合起来的查询，也能满足所以能匹配符合索引前缀的查询。

db.person.createIndex( {age: 1, name: 1} )

它针对多个字段联合创建索引，先按第一个字段排序，第一个字段相同的文档按第二个字段排序，依次类推，如下针对age, name这2个字段创建一个复合索引。

适用于：

db.person.find( {age： 18， name: "jack"} )
db.person.find( {age： 18} )

但是以下不能用上面的索引(因为是先按age后按name排序)：

db.person.find( {name: "jack"} )

应该建立：

db.person.createIndex( {name: 1} )
db.person.createIndex( {name: 1，age:1} )

除了查询的需求能够影响索引的顺序，字段的值分布也是一个重要的考量因素，即使person集合所有的查询都是『name和age字段组合』（指定特定的name和age），字段的顺序也是有影响的。

age字段的取值很有限，即拥有相同age字段的文档会有很多；而name字段的取值则丰富很多，拥有相同name字段的文档很少；显然先按name字段查找，再在相同name的文档里查找age字段更为高效。

（3）多key索引(Multikey Index）

当索引的字段为数组时，创建出的索引称为多key索引，多key索引会为数组的每个元素建立一条索引，比如person表加入一个habbit字段（数组）用于描述兴趣爱好，需要查询有相同兴趣爱好的人就可以利用habbit字段的多key索引。

{"name" : "jack", "age" : 19, habbit: ["football, runnning"]}
db.person.createIndex( {habbit: 1} )  // 自动创建多key索引

当索引是内嵌文档中的字段时：

//注意这是加 " " 的！！！！！
db.person.createIndex( {"favorite.city": 1} )

（4）其他类型索引

哈希索引（Hashed Index）是指按照某个字段的hash值来建立索引，目前主要用于MongoDB Sharded Cluster的Hash分片，hash索引只能满足字段完全匹配的查询，不能满足范围查询等。

db.person.createIndex( {username:"hashed"} )

地理位置索引（Geospatial Index）能很好的解决O2O的应用场景，比如『查找附近的美食』、『查找某个区域内的车站』等。

文本索引（Text Index）能解决快速文本查找的需求，比如有一个博客文章集合，需要根据博客的内容来快速查找，则可以针对博客内容建立文本索引。

（5）索引额外属性

MongoDB除了支持多种不同类型的索引，还能对索引定制一些特殊的属性。

唯一索引 (unique index)：保证索引对应的字段不会出现相同的值，比如_id索引就是唯一索引。
TTL索引：可以针对某个时间字段，指定文档的过期时间（经过指定时间后过期或在某个时间点过期）
部分索引 (partial index): 只针对符合某个特定条件的文档建立索引，3.2版本才支持该特性
稀疏索引(sparse index): 只针对存在索引字段的文档建立索引，可看做是部分索引的一种特殊情况。所有从索引中检索时效率高

（三）索引优化

（1）db profiling

MongoDB支持对DB的请求进行profiling，目前支持3种级别的profiling。

0：不开启profiling
1：将处理时间超过某个阈值(默认100ms)的请求都记录到DB下的system.profile集合
（类似于mysql、redis的slowlog）
2：将所有的请求都记录到DB下的system.profile集合（生产环境慎用）

通常，生产环境建议使用1级别的profiling，并根据自身需求配置合理的阈值，用于监测慢请求的情况，并及时的做索引优化。

如果能在集合创建的时候就能『根据业务查询需求决定应该创建哪些索引』，当然是最佳的选择；但由于业务需求多变，要根据实际情况不断的进行优化。索引并不是越多越好，集合的索引太多，会影响写入、更新的性能，每次写入都需要更新所有索引的数据；所以你system.profile里的慢请求可能是索引建立的不够导致，也可能是索引过多导致。

（2）查询计划

索引已经建立了，但查询还是很慢怎么破？这时就得深入的分析下索引的使用情况了，可通过查看下详细的查询计划来决定如何优化。通过执行计划可以看出如下问题查询计划

根据某个/些字段查询，但没有建立索引
根据某个/些字段查询，但建立了多个索引，执行查询时没有使用预期的索引。

（四）索引命令

（1）首先你用：

db.collectionname.remove({})

这样删除文档是删了，但是索引还在！！！

只有这样：

 db.collectionname.drop()

才能把这个集合的索引和文档删除了。(相当于在Compass工具上删了）

结论：集合清空后,索引自动删除，文档删除后，被删除文档对应的索引还在。

（2）索引基本命令

查看数据库中所有索引信息：

db.system.indexes.find()

查看某个集合中的索引：

db.COLLECTION_NAME.getIndexes()

查看集合中的索引大小：

db.COLLECTION_NAME.totalIndexSize()

删除索引(只剩下 _id 这一唯一索引)：

db.COLLECTION_NAME.dropIndexes()

删除指定的索引：

db.sites.dropIndex("name_1_domain_-1")

重建某集合上所有索引：

db.users.reIndex()

创建单键唯一索引：

db.users. createIndex({username :1},{unique:true})

复合唯一稀疏索引：

db.users. createIndex({username:1,age:-1},{unique:true,sparse:true})

创建哈希索引并后台运行：

db.users. createIndex({username :'hashed'},{background:true})

background：
是否后台构建索引,在生产环境中,如果数据量太大,构建索引可能会消耗很长时间,为了不影响业务,可以加上此参数,后台运行同时还会为其他读写操作让路

（3）索引命令explain()

整体来说，explain()的用法和sort()、limit()用法差不多，不同的是explain()必须放在最后面。

 db.indeX.find({"username":"0.47606255085396254"}).pretty().explain()

{"queryPlanner" : {"plannerVersion" : 1,"namespace" : "richfit_mongodb.indeX","indexFilterSet" : false,"parsedQuery" : {"username" : {"$eq" : "0.47606255085396254"}},"queryHash" : "379E82C5","planCacheKey" : "965E0A67","winningPlan" : {"stage" : "FETCH","inputStage" : {"stage" : "IXSCAN","keyPattern" : {"username" : 1},"indexName" : "username_1","isMultiKey" : false,"multiKeyPaths" : {"username" : [ ]},"isUnique" : false,"isSparse" : false,"isPartial" : false,"indexVersion" : 2,"direction" : "forward","indexBounds" : {"username" : ["[\"0.47606255085396254\", \"0.47606255085396254\"]"]}}},"rejectedPlans" : [ ]},"serverInfo" : {"host" : "PC-20200215WSBG","port" : 27017,"version" : "4.2.5","gitVersion" : "2261279b51ea13df08ae708ff278f0679c59dc32"},"ok" : 1
}

返回结果包含两大块信息，一个是queryPlanner，即查询计划，还有一个是serverInfo，即MongoDB服务的一些信息。那么这里涉及到的参数比较多，我们来一一看一下：

explain()也接收不同的参数，通过设置不同参数我们可以查看更详细的查询计划。例如：

添加 executionStats(其他参数也这样加就行)

db.indeX.find({"username":"0.47606255085396254"}).pretty().explain("executionStats")

{"queryPlanner" : {"plannerVersion" : 1,"namespace" : "sang.sang_collect","indexFilterSet" : false,"parsedQuery" : {},"winningPlan" : {"stage" : "COLLSCAN","direction" : "forward"},"rejectedPlans" : []},"executionStats" : {"executionSuccess" : true,"nReturned" : 10000,"executionTimeMillis" : 4,"totalKeysExamined" : 0,"totalDocsExamined" : 10000,"executionStages" : {"stage" : "COLLSCAN","nReturned" : 10000,"executionTimeMillisEstimate" : 0,"works" : 10002,"advanced" : 10000,"needTime" : 1,"needYield" : 0,"saveState" : 78,"restoreState" : 78,"isEOF" : 1,"invalidates" : 0,"direction" : "forward","docsExamined" : 10000}},"serverInfo" : {"host" : "localhost.localdomain","port" : 27017,"version" : "3.4.9","gitVersion" : "876ebee8c7dd0e2d992f36a848ff4dc50ee6603e"},"ok" : 1.0
}

这里除了我们上文介绍到的一些参数之外，还多了executionStats参数，含义如下：

通过totalDocsExamined:文档扫描次数，没有索引则全盘扫描，数据条数即文档扫描次数。totalKeysExamined：索引扫描条数，没有索引则为0。stage为COLLSCAN(为全盘扫描)则没有使用索引，stage为IXSCAN 则为索引扫描。通过这个就可以判断操作时是否使用了索引。当然其他有的时间属性也可以

理想状态是：nReturned=totalKeysExamined=totalDocsExamined。
nReturned为最后返回的结果文档数量。因为这样说明每一次扫描的数据都是符合查询要求的数据，每一次的扫描都没有白费。

还可以添加 allPlansExecution：

allPlansExecution用来获取所有执行计划，结果参数基本与上文相同，这里就不再细说了。

（4）Hint(强迫使用索引或不适用索引)

虽然MongoDB查询优化器一般工作的很不错，但是也可以使用hint()来强迫MongoDB使用一个特定的索引。在这种方法下某些情形下会提升性能。一个有索引的collection并且执行一个多字段的查询。传入一个制定的索引，强迫查询使用该索引。

db.users.find({"username":"user1000", "age":30}).hint({"username":1})

注意：请确定你已经创建了相应的索引。

假设在users上有个{“a”: 1, “b”: 1}的索引，名称是"a_1_b_1"，则如下两种方式等价：

db.users.find({"a": 4, "b": 5, "c": 6}).hint({"a": 1, "b": 1})
db.users.find({"a": 4, "b": 5, "c": 6}).hint("a_1_b_1")

也可以强迫查询不适用索引，做表扫描：

db.users.find().hint({"$natural":1})

db.byuser.find({"name":"jko"}).hint({"$natural":1}).pretty().explain("executionStats")

这样来看hint是否起效果

MongoDb（六）索引原理和命令相关推荐

mysql六:索引原理与慢查询优化
一介绍为何要有索引? 一般的应用系统,读写比例在10:1左右,而且插入操作和一般的更新操作很少出现性能问题,在生产环境中,我们遇到最多的,也是最容易出问题的,还是一些复杂的查询操作,因此对查询语句 ...
Mongodb Geo2d索引原理
MongoDB的geo索引是其一大特色,本文从原理层面讲述geo索引中的2d索引的实现. 2d 索引的创建与使用通过 db.coll.createIndex({"lag":&qu ...
MongoDB索引原理及实践
背景数据库的演进随着计算机的发展,越来越多的数据需要被处理,数据库是为处理数据而产生.从概念上来说,数据库是指以一定的方式存储到一起,能为多个用户共享,具有更可能小的冗余,与应用程序彼此独立的数据 ...
MongoDB · 引擎特性 · MongoDB索引原理
MongoDB · 引擎特性 · MongoDB索引原理数据库内核月报原文链接 http://mysql.taobao.org/monthly/2018/09/06/ 为什么需要索引? 当你抱怨M ...
带你了解什么是MySQL数据库（六）索引原理，如何建立与使用索引
文章目录前言索引原理介绍查找二叉树.平衡二叉树.B树.B+树聚集索引与非聚集索引索引管理测试索引正确使用索引联合索引索引下推技术索引优化神器常见慢查询优化前言学习过某一门编 ...
MongoDB快速上手、windows安装、常用命令、文档基本增删改查、mongoDB的索引
MongoDB快速上手目标理解MongoDB的业务场景.熟悉MongoDB的简介.特点和体系结构.数据类型等. 能够在Windows和Linux下安装和启动MongoDB.图形化管理界面Compa ...
mongodb学习(六)索引
准备工作: 先插入100万条数据 for(i=0;i<=1000000;i++){db.users.insert({"i":i,"username":&q ...
MongoDB索引原理和具体使用
1. MongoDB 索引是用来干嘛? 索引通常能够极大的提高查询的效率,如果没有索引,MongoDB在读取数据时必须扫描集合中的每个文件并选取那些符合查询条件的记录. 这种扫描全集合的查询效率是非常 ...
Python mysql 索引原理与慢查询优化
一介绍为何要有索引? 一般的应用系统,读写比例在10:1左右,而且插入操作和一般的更新操作很少出现性能问题,在生产环境中,我们遇到最多的,也是最容易出问题的,还是一些复杂的查询操作,因此对查询语句 ...
cpci检索为什么那么慢_索引原理与慢查询优化
一.前言为何要有索引? 一般的应用系统,读写比例在10:1左右,而且插入操作和一般的更新操作很少出现性能问题,在生产环境中,我们遇到最多的,也是最容易出问题的,还是一些复杂的查询操作,因此对查询语句 ...

MongoDb（六）索引原理和命令

MongoDb（六）索引原理和命令相关推荐

最新文章

热门文章