想来接触mongodb它已经快一年了，对于其指数已经积累了很多的经验，知识，以这个夜黑风高的优势，放mongodb总结一番吧。
一，索引介绍
mongodb具有两类索引，分别为单键索引和复合索引。
1.单键索引是最简单的一种索引。创建单键索引的开销要比复合索引小非常多。单键索引主要用于针对单值查询的条件。
2.复合索引是将文档中的几个键联合起来创建的一种索引，创建这样的索引须要很多其它的空间与性能开销。分别体如今：
1).在给大量数据创建复合索引时。会堵塞数据库的查询，更不用说改动和插入操作了；
2).插入一条数据时，要花费很多其它的时间来给复合索引加数据；
3).创建的复合索引所站得空间大小依据数据的类型以及键的数量而有所不同。比方，假设你用五个NumberInt的键创建的复合索引的空间大小，并不会比两个NumberInt和一个String类型创建的复合索引占用很多其它的空间。索引在设计数据类型时，尽量将数据类型设置为NumberInt类型，以及尽量少使用string类型的数据做索引。
二，创建索引
创建索引的语句非常easy。
1.单键索引的创建：db.test.ensureIndex({name:1},{name:'index_name'})
2.复合索引的创建：db.test.ensureIndex({name:1,age:1,sex:1},{name:'index_nas'})
三。索引优化
索引的优化是一个重头戏。须要具体的来解释。我得測试数据插入了100万条。
字段分别为name,sex,type,time,id
1.我们来看一个简单的查询：db.test.find({name:'name_1'}) 相信大家对这个查询已经非常熟悉了。然后我们来看看这个语句的索引运行计划：
{
"cursor" : "BasicCursor", 查询语句所用到的索引。而BasicCursor代表没有索引
"isMultiKey" : false, 是否为复合索引
"n" : 1, 查询到的结果数
"nscannedObjects" : 1000000, 扫描的文档数量
"nscanned" : 1000000, 扫面的索引数量
"nscannedObjectsAllPlans" : 1000000, //影响的全部的被扫描文档的总数量
"nscannedAllPlans" : 1000000, //全部被扫描的索引的总数量
"scanAndOrder" : false, 是否排序
"indexOnly" : false,
"nYields" : 2,
"nChunkSkips" : 0,
"millis" : 342, 花费的时间
"indexBounds" : {
},
"server" : "node1:27017"
}
从这个运行计划中能够看出。该条查询语句查询一条数据须要扫描整个表，这肯定扯淡了嘛。那这时候就该给这个字段创建索引了。创建一个单键索引
db.test.ensureIndex({name:1},{name:'index_name'})
创建完索引之后。再来查看看这条查询语句的运行计划：
{
"cursor" : "BtreeCursor index_name",
"isMultiKey" : false,
"n" : 1,
"nscannedObjects" : 1,
"nscanned" : 1,
"nscannedObjectsAllPlans" : 1,
"nscannedAllPlans" : 1,
"scanAndOrder" : false,
"indexOnly" : false,
"nYields" : 0,
"nChunkSkips" : 0,
"millis" : 0,
"indexBounds" : {
"name" : [
[
"name_1",
"name_1"
]
]
},
"server" : "node1:27017"
}
简直是逆天啊。nscanned和nscannedObjects竟然从100万下降到1条，也就是查询数据时，仅仅扫描了一条就已经找到。并且花费的时间是0秒，没有创建索引时，竟然是342毫秒。绝对索引威武啊。
2.这时候我想通过type和sex来组合查询某一条件的数据: db.test.find({type:1,sex:0}) 看看这句的运行计划：
{
"cursor" : "BasicCursor",
"isMultiKey" : false,
"n" : 55555,
"nscannedObjects" : 1000000,
"nscanned" : 1000000,
"nscannedObjectsAllPlans" : 1000000,
"nscannedAllPlans" : 1000000,
"scanAndOrder" : false,
"indexOnly" : false,
"nYields" : 0,
"nChunkSkips" : 0,
"millis" : 529,
"indexBounds" : {
},
"server" : "node1:27017"
}
从这个计划中能够看出。为了查找几万条数据，它也扫描了整个表，非常显然，该创建索引了：
db.test.ensureIndex({type:1,sex:1},{name:'index_ts'})
创建完索引之后，再来运行查询语句。看看运行计划：
db.test.find({type:1,sex:0}).explain()
{
"cursor" : "BtreeCursor index_ts",
"isMultiKey" : false,
"n" : 55555,
"nscannedObjects" : 55555,
"nscanned" : 55555,
"nscannedObjectsAllPlans" : 55555,
"nscannedAllPlans" : 55555,
"scanAndOrder" : false,
"indexOnly" : false,
"nYields" : 0,
"nChunkSkips" : 0,
"millis" : 112,
"indexBounds" : {
"type" : [
[
1,
1
]
],
"sex" : [
[
0,
0
]
]
},
"server" : "node1:27017"
}
非常显然，绝对是一个最佳索引，由于n=nscannedObjects=nscanned了，并且查询时间从529毫秒下降到112毫秒了，这也是一个质的飞跃，能够明显的看到，它使用了刚刚创建的index_ts索引。
如今我又有一个需求了。我想通过时间再来排序，好的。我们运行查询语句： db.test.find({type:1,sex:0}).sort({time:-1}) 我们来看看这个查询语句的运行计划：
{
"cursor" : "BtreeCursor index_ts",
"isMultiKey" : false,
"n" : 55555,
"nscannedObjects" : 1000000,
"nscanned" : 1000000,
"nscannedObjectsAllPlans" : 1000000,
"nscannedAllPlans" : 1000000,
"scanAndOrder" : true,
"indexOnly" : false,
"nYields" : 1,
"nChunkSkips" : 0,
"millis" : 695,
"indexBounds" : {
"type" : [
[
1,
1
]
],
"sex" : [
[
0,
0
]
]
},
"server" : "node1:27017"
}
看到没。这个查询语句跟上一个创建索引之后的查询出来的结果相差还是非常大的，scanAndOrder和millis,时间花费了将近700毫秒，并且在查询完成之后还要排序，这也太不近人情了，就加了一个排序操作，怎么会让它从白天鹅变成丑小鸭了呢？啊，关键參数就是scanAndOrder，意思就是在内存中把结果排序了嘛。那好啊，既然你如此薄情。那我就建个复合索引来对抗: db.test.ensureIndex({type:1,sex:1,time:-1},{name:'index_tst'})
{
"cursor" : "BtreeCursor index_tst",
"isMultiKey" : false,
"n" : 55555,
"nscannedObjects" : 55555,
"nscanned" : 55555,
"nscannedObjectsAllPlans" : 55555,
"nscannedAllPlans" : 55555,
"scanAndOrder" : false,
"indexOnly" : false,
"nYields" : 0,
"nChunkSkips" : 0,
"millis" : 126,
"indexBounds" : {
"type" : [
[
1,
1
]
],
"sex" : [
[
0,
0
]
],
"time" : [
[
{
"$maxElement" : 1
},
{
"$minElement" : 1
}
]
]
},
"server" : "node1:27017"
}
看到了吗？各种參数又回到最佳状态了。这时候可能有人会问了，为什么要把time放到索引的最后而不是其他位置呢？事实上这在创建索引时是有要求的。即：
-
将等值索引放在最前面
-
尽量将排序字段放在范围字段的后面
-
$nin和$ne跟索引没有关系
接下来我们再给查询语句加条件： db.test.find({type:1,sex:0,id:{$gt:1,$lt:500000}}) 运行计划例如以下:
{
"cursor" : "BasicCursor",
"isMultiKey" : false,
"n" : 55555,
"nscannedObjects" : 1000000,
"nscanned" : 1000000,
"nscannedObjectsAllPlans" : 1000000,
"nscannedAllPlans" : 1000000,
"scanAndOrder" : false,
"indexOnly" : false,
"nYields" : 2,
"nChunkSkips" : 0,
"millis" : 553,
"indexBounds" : {
},
"server" : "node1:27017"
}
能够看到，仅仅返回两万多条数据，可是却扫描了整个表，这肯定是非常蛋疼的事情嘛，索引走起：
db.test.ensureIndex({type:1,sex:1,id:1},{name:'index_tis'})
{
"cursor" : "BtreeCursor index_tis",
"isMultiKey" : false,
"n" : 55555,
"nscannedObjects" : 55555,
"nscanned" : 55555,
"nscannedObjectsAllPlans" : 55555,
"nscannedAllPlans" : 55555,
"scanAndOrder" : false,
"indexOnly" : false,
"nYields" : 1,
"nChunkSkips" : 0,
"millis" : 137,
"indexBounds" : {
"type" : [
[
1,
1
]
],
"sex" : [
[
0,
0
]
],
"id" : [
[
1,
1000000
]
]
},
"server" : "node1:27017"
}
非常显然，这是个非常不错的组合索引，那为何不把id放在其他地方。偏偏放在最后面呢？由于在mongodb中，索引是从左到右运行的。因此显然要从左到右一次过滤最大数量的数据显然type和sex的组合过滤数据量要比id高很多其他，由于id的忙查率要远高于这两个组合。
接着再把按time排序加上。查询：db.test.find({type:1,sex:1,id:{$gt:0,$lt:1000000}}).sort({time:-1}).explain()
{
"cursor" : "BasicCursor",
"isMultiKey" : false,
"n" : 55556,
"nscannedObjects" : 1000000,
"nscanned" : 1000000,
"nscannedObjectsAllPlans" : 1000000,
"nscannedAllPlans" : 1000000,
"scanAndOrder" : true,
"indexOnly" : false,
"nYields" : 1,
"nChunkSkips" : 0,
"millis" : 725,
"indexBounds" : {
},
"server" : "node1:27017"
}
能够看到。这个查询语句也是极其慢的，并且还要再内存中排序，所以肯定要创建索引了：
db.test.ensureIndex({type:1,sex:1,id:1,time:-1},{name:'index_tist'}) 我们先这样创建索引，看看运行计划：
{
"cursor" : "BtreeCursor index_tist",
"isMultiKey" : false,
"n" : 55556,
"nscannedObjects" : 55556,
"nscanned" : 55556,
"nscannedObjectsAllPlans" : 55657,
"nscannedAllPlans" : 55657,
"scanAndOrder" : true,
"indexOnly" : false,
"nYields" : 0,
"nChunkSkips" : 0,
"millis" : 404,
"indexBounds" : {
"type" : [
[
1,
1
]
],
"sex" : [
[
1,
1
]
],
"id" : [
[
0,
1000000
]
],
"time" : [
[
{
"$maxElement" : 1
},
{
"$minElement" : 1
}
]
]
},
"server" : "node1:27017"
}
看到了没有，尽管查询时间缩短了。可是这个查询结果还是会排序结果，好，我们再把索引改改：
db.test.ensureIndex({type:1,sex:1,time:-1,id:1},{name:'index_tist'})
{
"cursor" : "BtreeCursor index_tist",
"isMultiKey" : false,
"n" : 55556,
"nscannedObjects" : 55556,
"nscanned" : 55556,
"nscannedObjectsAllPlans" : 55657,
"nscannedAllPlans" : 55657,
"scanAndOrder" : false,
"indexOnly" : false,
"nYields" : 0,
"nChunkSkips" : 0,
"millis" : 168,
"indexBounds" : {
"type" : [
[
1,
1
]
],
"sex" : [
[
1,
1
]
],
"time" : [
[
{
"$maxElement" : 1
},
{
"$minElement" : 1
}
]
],
"id" : [
[
0,
1000000
]
]
},
"server" : "node1:27017"
}
再来看看，快到什么程度了，这个查询的速度和參数条件已经比上一个索引的快了非常多，那为什么会出现这样的情况呢？为什么time在id的前后会有不同的表现？这是由于通过type和sex字段过滤完之后，已经在内存中有了数据，而这些数据下一步须要怎么办？是先通过id来筛选，还是依照排序筛选呢？这里有一个知识点，在把id放在time前面时，程序首先会取复合id值，然后再把复合的数据排序，可是假设id放在排序的后面。那么程序将直接通过顺序扫描索引树的方式取出复合id范围的数据。
四，总结
1.mongodb创建索引难点在于排序和范围查询的字段位置选择
2.mongodb的复合索引的索引截取查询是顺序的，即假设(a:1,b:1,c:1},则能够是查询{a:1},{a:1,b:1},{a:1,b:1,c:1}中得不论什么一种都会使用该索引。其他查询情况将不会用到该索引；
3.尝试创建一个更小的索引，以提高数据库的性能
4.上述指标优化生产环境的一部分，这可能取决于自己的企业来决定的细节