Mongodb索引
一、索引基础：
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将会报错。
二、唯一索引：
在缺省情况下创建的索引均不是唯一索引。下面的示例将创建唯一索引，如：
> 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})
三、使用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});
删除所有索引
四、索引管理：
system.indexes集合中包含了每个索引的详细信息，因此可以通过下面的命令查询已经存在的索引，如：
> db.system.indexes.find()
如果在为已有数据的文档创建索引时，可以执行下面的命令，以使MongoDB在后台创建索引，这样的创建时就不会阻塞其他操作。但是相比而言，以阻塞方式创建索引，会使整个创建过程效率更高，但是在创建时MongoDB将无法接收其他的操作。
> db.test.ensureIndex({"username":1},{"background":true})
关于索引的建议
我们收到了很多关于索引的问题。这一部分解答了其中的一小部分。有几点要记住。
第一,MongoDB索引和MySQL索引非常相似并且对于MySQL的索引优化有很多也适用于MongoDB。
第二，更重要的是，这些索引的建议对你的应用提高也是有限的。
对于应用的最佳索引策略应该基于很多的重要因素。包含了你期望查询的类型，
数据读取与写入的比率，甚至于你服务器的空闲内存。意思就是，
需要对线上的产品做很多的测试剖析工作，才能调整出最佳的索引策略。
没有什么好的方法可以替代实际经验的。
索引策略
下面有些索引的基本法则
创建的索引要匹配查询。
如果你仅仅要查询单个字段。索引这个字段即可。如
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输出主要有三个字段：
- cursor: 游标不是 BasicCursor就是 BtreeCursor. 第二种意味着使用了索引。
- nscanned: 扫描document的行数。
- n: 查询返回的行数。你希望n的值和nsanned值接近。要避免做collection的扫描，
- 也就是访问所有的document。
- millis: 查询完成的毫秒数。这个对于比较索引和非索引性能非常有用。
要关注应用读/写( read/write) 比率
这个很重要，因为，添加索引意味着添加，更新，删除操作变慢。
如果你的应用是偏向于读取，使用索引是非常好的事情。
但是如果你的应用偏向于写，那么创建索引就要小心了。增加索引都很影响写入的性能。
一般来说, 不要随便添加索引。索引应该按照你的查询来添加。
添加索引的理由总是很多的, 以及要进行大量的测试选择合适的索引策略。
索引特性
组合索引有许多特性要记住。
下面的例子都假想在 a, b, c上创建组合索引。因此创建索引语句如下
db.foo.ensureIndex({a: 1, b: 1, c: 1})
1. 排序的列一定要在索引的最后。
好的:
- find(a=1).sort(a)
- find(a=1).sort(b)
- find(a=1, b=2).sort(c)
不好的:
- find(a=1).sort(c)
- 即使c是索引的最后一列，a列是所使用的最后一列，因此你只能通过a或者b列进行排序。
5. MongoDB's $ne 或者$nin 操作在索因伤是无效的。
当要排除很少的documents。最好的方法就是在MongoDB查询出结果，在服务端进行排除。
