1、索引基础:
MongoDB的索引几乎与传统的关系型数据库如出一辙,这其中也包括一些基本的优化技巧。下面是建立索引的命令:
> db.test.ensureIndex({"username":1})
能够经过下面的名称查看索引是否已经成功创建:
> db.test.getIndexes()
删除索引的命令是:
> db.test.dropIndex({"username":1})
在MongoDB中,咱们一样能够建立复合索引,如:
-- 数字1表示username键的索引按升序存储,-1表示age键的索引按照降序方式存储。
> db.test.ensureIndex({"username":1, "age":-1})
该索引被建立后,基于username和age的查询将会用到该索引,或者是基于username的查询也会用到该索引,可是只是基于age的查询将不会用到该复合索引。所以能够说,若是想用到复合索引,必须在查询条件中包含复合索引中的前N个索引列。然而若是查询条件中的键值顺序和复合索引中的建立顺序不一致的话,MongoDB能够智能的帮助咱们调整该顺序,以便使复合索引能够为查询所用。如:
> db.test.find({"age": 30, "username": "stephen"})
对于上面示例中的查询条件,MongoDB在检索以前将会动态的调整查询条件文档的顺序,以使该查询能够用到刚刚建立的复合索引。
咱们能够为内嵌文档建立索引,其规则和普通文档没有任何差异,如:
> db.test.ensureIndex({"comments.date":1})
对于上面建立的索引,MongoDB都会根据索引的keyname和索引方向为新建立的索引自动分配一个索引名,下面的命令能够在建立索引时为其指定索引名,如:
> db.test.ensureIndex({"username":1},{"name":"testindex"})
随着集合的增加,须要针对查询中大量的排序作索引。若是没有对索引的键调用sort,MongoDB须要将全部数据提取到内存并排序。所以在作无索引排序时,若是数据量过大以至没法在内存中进行排序,此时MongoDB将会报错。
2、惟一索引:
在缺省状况下建立的索引均不是惟一索引。下面的示例将建立惟一索引,如:
> db.test.ensureIndex({"userid":1},{"unique":true})
若是再次插入userid重复的文档时,MongoDB将报错,以提示插入重复键,如:
> db.test.insert({"userid":5})
> db.test.insert({"userid":5})
E11000 duplicate key error index: test.test.$userid_1 dup key: { : 5.0 }
若是插入的文档中不包含userid键,那么该文档中该键的值为null,若是屡次插入相似的文档,MongoDB将会报出一样的错误,如:
> db.test.insert({"userid1":5})
> db.test.insert({"userid1":5})
E11000 duplicate key error index: test.test.$userid_1 dup key: { : null }
若是在建立惟一索引时已经存在了重复项,咱们能够经过下面的命令帮助咱们在建立惟一索引时消除重复文档,仅保留发现的第一个文档,如:
--先删除刚刚建立的惟一索引。
> db.test.dropIndex({"userid":1})
--插入测试数据,以保证集合中有重复键存在。
> db.test.remove()
> db.test.insert({"userid":5})
> db.test.insert({"userid":5})
--建立惟一索引,并消除重复数据。
> db.test.ensureIndex({"userid":1},{"unique":true,"dropDups":true})
--查询结果确认,重复的键确实在建立索引时已经被删除。
> db.test.find()
{ "_id" : ObjectId("4fe823c180144abd15acd52e"), "userid" : 5 }
咱们一样能够建立复合惟一索引,即保证复合键值惟一便可。如:
> db.test.ensureIndex({"userid":1,"age":1},{"unique":true})
3、使用explain:
explain是很是有用的工具,会帮助你得到查询方面诸多有用的信息。只要对游标调用该方法,就能够获得查询细节。explain会返回一个文档,而不是游标自己。如:
> db.test.find().explain()
{
"cursor" : "BasicCursor",
"nscanned" : 1,
"nscannedObjects" : 1,
"n" : 1,
"millis" : 0,
"nYields" : 0,
"nChunkSkips" : 0,
"isMultiKey" : false,
"indexOnly" : false,
"indexBounds" : {
}
}
explain会返回查询使用的索引状况,耗时和扫描文档数的统计信息。
"cursor":"BasicCursor"表示没有使用索引。
"nscanned":1 表示查询了多少个文档。
"n":1 表示返回的文档数量。
"millis":0 表示整个查询的耗时。
mongodb的是B-tree的索引了。要注意的是,一个collection不能超过64个索引,
索引的大小不能超过1024字节,其中包括字段名和值和命名空间。
首先照样建立数据:
db.Indexing.insert( { name : "Denis", age : 20 } )
db.Indexing.insert( { name : "Abe", age : 30 } )
db.Indexing.insert( { name : "John", age : 40 } )
db.Indexing.insert( { name : "Xavier", age : 10 } )
db.Indexing.insert( { name : "Zen", age : 50 } )
首先,尝试看下mongodb的执行计划:
db.Indexing.find({name: "Denis"}).explain(),这个是看当查找Denis的执行状况,
结果以下:
{
"cursor" : "BasicCursor",
"isMultiKey" : false,
"n" : 0,
"nscannedObjects" : 0,
"nscanned" : 0,
"nscannedObjectsAllPlans" : 0,
"nscannedAllPlans" : 0,
"scanAndOrder" : false,
"indexOnly" : false,
"nYields" : 0,
"nChunkSkips" : 0,
"millis" : 0,
"indexBounds" : {
},
"server" : "Denis:27017"
}
下面加个索引,以下:
db.Indexing.ensureIndex({name: 1});
其中依然,1是升序,-1是降序,再看下执行计划:
db.Indexing.find({name: "Denis"}).explain()
结果为:
{
"cursor" : "BtreeCursor name_1",
"isMultiKey" : false,
"n" : 1,
"nscannedObjects" : 1,
"nscanned" : 1,
"nscannedObjectsAllPlans" : 1,
"nscannedAllPlans" : 1,
"scanAndOrder" : false,
"indexOnly" : false,
"nYields" : 0,
"nChunkSkips" : 0,
"millis" : 1,
"indexBounds" : {
"name" : [
[
"Denis",
"Denis"
]
]
},
"server" : "Denis:27017"
}
能够看到,"cursor" 一栏中,已经变成了btree了;而且"indexBounds" :中如今有内容了。
而后能够删除索引:
db.Indexing.dropIndex({name: 1});
删除全部索引
4、索引管理:
system.indexes集合中包含了每一个索引的详细信息,所以能够经过下面的命令查询已经存在的索引,如:
> db.system.indexes.find()
若是在为已有数据的文档建立索引时,能够执行下面的命令,以使MongoDB在后台建立索引,这样的建立时就不会阻塞其余操做。可是相比而言,以阻塞方式建立索引,会使整个建立过程效率更高,可是在建立时MongoDB将没法接收其余的操做。
> db.test.ensureIndex({"username":1},{"background":true})mongodb
关于索引的建议数据库
咱们收到了不少关于索引的问题。这一部分解答了其中的一小部分。有几点要记住。服务器
第一,MongoDB索引和MySQL索引很是类似而且对于MySQL的索引优化有不少也适用于MongoDB。工具
第二,更重要的是,这些索引的建议对你的应用提升也是有限的。post
对于应用的最佳索引策略应该基于不少的重要因素。包含了你指望查询的类型,性能
数据读取与写入的比率,甚至于你服务器的空闲内存。意思就是,测试
须要对线上的产品作不少的测试剖析工做,才能调整出最佳的索引策略。优化
没有什么好的方法能够替代实际经验的。spa
索引策略orm
建立的索引要匹配查询。
若是你仅仅要查询单个字段。索引这个字段便可。如
db.posts.find({ slug : 'state-of-mongodb-2010' })
这个例子中,惟一索引是最佳的
db.posts.ensureIndex({ slug: 1 }, {unique: true});
然而,通常都查询多个键而且排序结果。这种状况,组合索引是最佳的,例子以下
db.comments.find({ tags : 'mongodb'}).sort({ created_at : -1 });
建立的索引以下
db.comments.ensureIndex({tags : 1, created_at : -1});
要注意的是若是咱们按照升序排序created_at。索引效率就低下了。
每一个查询一个索引。
有的时候查询多个键,须要多个索引。在MongoDB中,这么作没问题。
若是你有个查询要匹配多个键,而且你想更有效地使用索引,请使用组合索引。
要肯定全部的索引都在RAM中。
Shell中提供了一个查看索引大小的命令,以下:
db.comments.totalIndexSize();
65443
若是你的查询有点迟缓,你应该查看下索引是否都存入到RAM中了。
一个实例,若是你运行在4GB的RAM机器而且有3GB的索引,那么索引可能并不能全存在RAM中。
你须要添加RAM以及/或者校验实际的索引使用量。
要当心单键索引的低选择性。
假使你有个字段叫作'status',就有两个值new和processed。
若是在status上建立索引那么这就是个低选择性的索引。
意味着,查询中没有什么优点而且还占大量的空间。
一个更好一点的策略,固然依赖具体查询需求,能够建立组合索引包括这个低选择性的字段。
举例来讲,你能够建立一个组合索引在status和created_at字段上。
另外一个选择,固然也依赖你的需求,能够分离collection, 一个状态一个。
固然这些建议必定要进行测试,选择最优的方案。
使用explain.
MongoDB提供了一个explain命令,
用来查看查询的过程而且能够查看是否使用缩影。explain能够在驱动中使用,也能够在SHELL中使用:
db.comments.find({ tags : 'mongodb'}).sort({ created_at : -1 }).explain();
若是你历来没有使用过explain,请开始使用吧。
理解explain的 输出.
explain输出主要有三个字段:
要关注应用读/写( read/write) 比率
这个很重要,由于,添加索引意味着添加,更新,删除操做变慢。
若是你的应用是偏向于读取,使用索引是很是好的事情。
可是若是你的应用偏向于写,那么建立索引就要当心了。增长索引都很影响写入的性能。
通常来讲, 不要随便添加索引。索引应该按照你的查询来添加。
添加索引的理由老是不少的, 以及要进行大量的测试选择合适的索引策略。
索引特性
组合索引有许多特性要记住。
下面的例子都假想在 a, b, c上建立组合索引。所以建立索引语句以下
db.foo.ensureIndex({a: 1, b: 1, c: 1})
1. 排序的列必定要在索引的最后。
好的:
很差的:
5. MongoDB's $ne 或者$nin 操做在索因伤是无效的。
当要排除不多的documents。最好的方法就是在MongoDB查询出结果,在服务端进行排除。