(一)索引基本介绍
索引是提高查询查询效率最有效的手段。索引是一种特殊的数据结构,索引以易于遍历的形式存储了数据的部分内容(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是否起效果