MongoDB之二:复合索引

索引用来优化查询,而且在某些特定类型的查询中,索引必不可少。 ---《MongoDB权威指南》

  • 直接创建100万条测试数据:
for(var i=0;i<1000000;i++){
    post={"user":"user: "+i,"age":Math.floor(Math.random(100)),"createAt":new Date()};
    db.foo.save(post);
}

PS: 以上代码可能要好几分钟才能执行完毕(时间直接跟你的电脑配置挂钩)。

完成以后直接执行查询看处理时间:
> db.foo.find({"user":"user: 105"}).explain("allPlansExecution")["executionStats"]["executionTimeMillis"]
> 316

可以看到在没有任何索引的时候查询一个值的时候使用的时间是316毫秒(不同配置的电脑查询时间不一样,反正查询时间不理想)

  • 为"user"字段创建索引:
// 创建索引
> db.foo.ensureIndex({"user":1})
再次执行查询:
> db.foo.find({"user":"user: 105"}).explain("allPlansExecution")["executionStats"]["executionTimeMillis"]
> 0

Emmmm,查询时间为0毫秒。。。(有点小夸张,理解为快了很多吧)

排序

  • 索引是按照一定顺序进行排序的,上面的{"user":1},索引会按照user字段进行升序排列,-1为降序排列,只有在索引的键上面进行排序,索引才会有用,以下查询排序用上面的索引没什么卵用:
> db.foo.find().sort({"age":1,"user":1})

优化以上这个排序,可以添加复合索引(两个或以上的键建立索引的时候,称为复合索引):

> db.foo.ensureIndex({"age":1,"user":1})

这个索引的每一条目都包含一个"age"键 和 一个"user"键,该索引首先会以"age"键进行升序排列,"age"相同的条目会以"user"进行升序排列。

这个时候如果你进行以下查询:

> db.foo.find({"age":10}).sort({"user":-1})

由于查询结果是已经有序的了("age" 为10的条目,"user"升序排列,上面说过),我们需要"user"为倒序排列,MongoDB会自动逆序进行索引遍历,所以最后得出的结果也是很快的:

> db.foo.find({"age":10}).sort({"user":-1}).explain("allPlansExecution")["executionStats"]["executionTimeMillis"]
> 18

结果是18毫秒可以查找到年龄为10并且为倒序排列的所有用户。

范围查询

如下:

> db.foo.find({"age":{"$gt":10,"$lt":35}}).explain("allPlansExecution")["executionStats"]["executionTimeMillis"]
> 398

emmm.这个查询需要398ms 好像有点不科学。
看看具体的查询过程:

 "executionStats" : {
                "executionSuccess" : true,
                "nReturned" : 239459,
                "executionTimeMillis" : 335,
                "totalKeysExamined" : 239459,
                "totalDocsExamined" : 239459,
             ......
                }

nReturned:需要返回的结果数量.
totalKeysExamined: 一共查找了多少次.
executionTimeMillis: 执行的总时长.

看来是只能这么快了,毕竟查找的次数跟需要返回的数量是一样的了。。

  • 需要范围查询同时需要排序:
> db.foo.find({"age":{"$gt":10,"$lt":35}}).sort({"user":-1}).explain("executionStats")["executionStats"]["executionTimeMillis"]
> 1229

花了1秒多。。。这个绝逼不科学。原因是因为"db.foo.find({"age":{"$gt":10,"$lt":35}})"这一句,索引是直接用"age"这个键进行查询,得到的结果按照"age"进行升序排列,但是这后面的"sort({"user":-1})"就完全需要MongoDB在内存中先排序完毕,再返回,可以键入命令看具体情况:

> db.foo.find({"age":{"$gt":10,"$lt":35}}).sort({"user":-1}).explain("executionStats")["executionStats"]

结果:

  "executionStats" : {
                "executionSuccess" : true,
                "nReturned" : 239459,
                "executionTimeMillis" : 1265,
                "totalKeysExamined" : 1000000,
                "totalDocsExamined" : 1000000,
              ......
}

进行了一次全表扫描并且要在内存里面排序,以至于需要一秒多.

这时候我们换一下索引,把需要排序的键放到前面来:

> db.foo.ensuerInsert({"user":1,"age":1})
> db.foo.find({"age":{$gt:10,$lt:35}}).hint({"user":1,"age":1}).sort({"user":-1}).explain("executionStats")["executionStats"]["executionTimeMillis"]
> 1663

emm...怎么还要1.6s呢。。其实嘛,重点是,当我们查询的时候,并不总是查全部数据,一般是查前面的一点数据,这个时候:

> db.foo.find({"age":{$gt:10,$lt:35}}).hint({"user":1,"age":1}).limit(1500).sort({"user":-1}).explain("executionStats")["executionStats"]["executionTimeMillis"]
> 11

//使用非查询键在前.
 db.foo.find({"age":{$gt:10,$lt:35}}).hint({"age":1,"user":1}).limit(1500).sort({"user":-1}).explain("executionStats")["executionStats"]["executionTimeMillis"]
//688

显而易见,只查询部分数据的时候使用索引的查询键在前面会有极大的速度提升。至于查询全部数据怎么提升性能,待研究。

  • 基于多方向排序

如果我们以上的程序要求结果以"sort("age":1,"user":-1)"进行排序,以上索引都不再高效。
原因上面也都说了 "ensureIndex({"age":1,"user":1})"是默认以"age"进行升序,相同条目再以"user"键进行升序。
如果需要匹配"sort("age":1,"user":-1)",则再添加一个索引:

db.foo.ensureIndex({"age":1,"user":-1})

只有基于多个方向进行排序时,索引方向才变得重要。
单方向排序的需求索引方向不重要,如"sort({"user":-1})",因为单键排序MongoDB可以简单的从反方向读取索引。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,362评论 5 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,330评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,247评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,560评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,580评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,569评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,929评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,587评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,840评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,596评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,678评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,366评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,945评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,929评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,165评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,271评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,403评论 2 342

推荐阅读更多精彩内容