索引就像书的目录,如果查找某内容在没有目录的帮助下,只能全篇查找翻阅,这导致效率非常的低下;如果在借助目录情况下,就能很快的定位具体内容所在区域,效率会直线提高。
索引简介
首先打开命令行,输入mongo。默认mongodb会连接名为test的数据库。
"htmlcode">> for(var i=0;i<100000;i++) { ... db.users.insert({username:'user'+i}) ... } > show collections system.indexes users >再查看数据库发现多了system.indexes 和 users两个表,前者即所谓的索引,后者为新建的数据库表。
这样user表中即有了10万条数据。> db.users.find() { "_id" : ObjectId("5694d5da8fad9e319c5b43e4"), "username" : "user0" } { "_id" : ObjectId("5694d5da8fad9e319c5b43e5"), "username" : "user1" } { "_id" : ObjectId("5694d5da8fad9e319c5b43e6"), "username" : "user2" } { "_id" : ObjectId("5694d5da8fad9e319c5b43e7"), "username" : "user3" } { "_id" : ObjectId("5694d5da8fad9e319c5b43e8"), "username" : "user4" } { "_id" : ObjectId("5694d5da8fad9e319c5b43e9"), "username" : "user5" }现在需要查找其中任意一条数据,比如
> db.users.find({username: 'user1234'}) { "_id" : ObjectId("5694d5db8fad9e319c5b48b6"), "username" : "user1234" }发现这条数据成功找到,但需要了解详细信息,需要加上explain方法
> db.users.find({username: 'user1234'}).explain() { "cursor" : "BasicCursor", "isMultiKey" : false, "n" : 1, "nscannedObjects" : 100000, "nscanned" : 100000, "nscannedObjectsAllPlans" : 100000, "nscannedAllPlans" : 100000, "scanAndOrder" : false, "indexOnly" : false, "nYields" : 0, "nChunkSkips" : 0, "millis" : 30, "indexBounds" : { }, "server" : "root:27017" }参数很多,目前我们只关注其中的"nscanned" : 100000和"millis" : 30这两项。
nscanned表示mongodb在完成这个查询过程中扫描的文档总数。可以发现,集合中的每个文档都被扫描了,并且总时间为30毫秒。
如果数据有1000万个,如果每次查询文档都遍历一遍。呃,时间也是相当可观。
对于此类查询,索引是一个非常好的解决方案。
> db.users.ensureIndex({"username": 1})然后再查找user1234
> db.users.ensureIndex({"username": 1}) > db.users.find({username: 'user1234'}).explain() { "cursor" : "BtreeCursor username_1", "isMultiKey" : false, "n" : 1, "nscannedObjects" : 1, "nscanned" : 1, "nscannedObjectsAllPlans" : 1, "nscannedAllPlans" : 1, "scanAndOrder" : false, "indexOnly" : false, "nYields" : 0, "nChunkSkips" : 0, "millis" : 0, "indexBounds" : { "username" : [ [ "user1234", "user1234" ] ] }, "server" : "root:27017" }的确有点不可思议,查询在瞬间完成,因为通过索引只查找了一条数据,而不是100000条。
当然使用索引是也是有代价的:对于添加的每一条索引,每次写操作(插入、更新、删除)都将耗费更多的时间。这是因为,当数据发生变化时,不仅要更新文档,还要更新级集合上的所有索引。因此,mongodb限制每个集合最多有64个索引。通常,在一个特定的集合上,不应该拥有两个以上的索引。
小技巧
如果一个非常通用的查询,或者这个查询造成了性能瓶颈,那么在某字段(比如username)建立索引是非常好的选择。但只是给管理员用的查询(不太在意查询耗费时间),就不该对这个字段建立索引。
复合索引
索引的值是按一定顺序排列的,所以使用索引键对文档进行排序非常快。
db.users.find().sort({'age': 1, 'username': 1})这里先根据age排序再根据username排序,所以username在这里发挥的作用并不大。为了优化这个排序,可能需要在age和username上建立索引。
db.users.ensureIndex({'age':1, 'username': 1})
这就建立了一个复合索引(建立在多个字段上的索引),如果查询条件包括多个键,这个索引就非常有用。建立复合索引后,每个索引条目都包括一个age字段和一个username字段,并且指向文档在磁盘上的存储位置。
此时,age字段是严格升序排列的,如果age相等时再按照username升序排列。查询方式
点查询(point query)
用于查询单个值(尽管包含这个值的文档可能有多个)
db.users.find({'age': 21}).sort({'username': -1})因为我们已经建立好复合索引,一个age一个username,建立索引时使用的是升序排序(即数字1),当使用点查询查找{age:21},假设仍然是10万条数据,可能年龄是21的很多人,因此会找到不只一条数据。然后sort({'username': -1})会对这些数据进行逆序排序,本意是这样。但我们不要忘记建立索引时'username':1是升序(从小到大),如果想得到逆序只要对数据从最后一个索引开始,依次遍历即可得到想要的结果。
排序方向并不重要,mongodb可以从任意方向对索引进行遍历。
综上,复合索引在点查询这种情况非常高效,直接定位年龄,不需要对结果进行排序,返回结果。多值查询(multi-value-query)
db.users.find({'age': {"$gte": 21, "$lte": 30}})查找多个值相匹配的文档。多值查询也可以理解为多个点查询。
如上,要查找年龄介于21到30之间。monogdb会使用索引的中的第一个键"age"得到匹配的结果,而结果通常是按照索引顺序排列的。db.users.find({'age': {"$gte": 21, "$lte": 30}}).sort({'username': 1})与上一个类似,这次需要对结果排序。
在没有sort时,我们查询的结果首先是根据age等于21,age等于22..这样从小到大排序,当age等于21有多个时,在进行usernameA-Z(0-9)这样排序。所以,sort({'username': 1}),要将所有结果通过名字升序排列,这次不得不先在内存中进行排序,然后返回。效率不如上一个高。当然,在文档非常少的情况,排序也花费不了多少时间。
如果结果集很大,比如超过32MB,MongoDB会拒绝对如此多的数据进行排序工作。还有另外一种解决方案
也可以建立另外一个索引{'username': 1, 'age': 1}, 如果先对username建立索引,当再sortusername,相当没有进行排序。但是需要在整个文档查找age等于21的帅哥美女,所以搜寻时间就长了。
但哪个效率更高呢?
如果建立多个索引,如何选择使用哪个呢?
效率高低是分情况的,如果在没有限制的情况下,不用进行排序但需要搜索整个集合时间会远超过前者。但是在返回部分数据(比如limit(1000)),新的赢家就产生了。>db.users.find({'age': {"$gte": 21, "$lte": 30}}). sort({username': 1}). limit(1000). hint({'age': 1, 'username': 1}) explain()['millis'] 2031ms >db.users.find({'age': {"$gte": 21, "$lte": 30}}). sort({username': 1}). limit(1000). hint({'username': 1, 'age': 1}). explain()['millis'] 181ms其中可以使用hint指定要使用的索引。
所以这种方式还是很有优势的。比如一般场景下,我们不会把所有的数据都取出来,只是去查询最近的,所以这种效率也会更高。索引类型
唯一索引
可以确保集合的每个文档的指定键都有唯一值。
db.users.ensureIndex({'username': 1, unique: true})
比如使用mongoose框架,在定义schema时,即可指定unique: true.
如果插入2个相同都叫张三的数据,第二次插入的则会失败。_id即为唯一索引,并且不能删除。稀疏索引
使用sparse可以创建稀疏索引
>db.users.ensureIndex({'email': 1}, {'unique': true, 'sparse': true})
索引管理
system.indexes集合中包含了每个索引的详细信息
db.system.indexes.find()
1.ensureIndex()创建索引
db.users.ensureIndex({'username': 1})
后台创建索引,这样数据库再创建索引的同时,仍然能够处理读写请求,可以指定background选项。db.test.ensureIndex({"username":1},{"background":true})
2.getIndexes()查看索引
db.collectionName.getIndexes() db.users.getIndexes() [ { "v" : 1, "key" : { "_id" : 1 }, "ns" : "test.users", "name" : "_id_" }, { "v" : 1, "key" : { "username" : 1 }, "ns" : "test.users", "name" : "username_1" } ]其中v字段只在内部使用,用于标识索引版本。
3.dropIndex删除索引
> db.users.dropIndex("username_1") { "nIndexesWas" : 2, "ok" : 1 }或
全选复制放进笔记> db.users.dropIndex({"username":1})
免责声明:本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除!
《魔兽世界》大逃杀!60人新游玩模式《强袭风暴》3月21日上线
暴雪近日发布了《魔兽世界》10.2.6 更新内容,新游玩模式《强袭风暴》即将于3月21 日在亚服上线,届时玩家将前往阿拉希高地展开一场 60 人大逃杀对战。
艾泽拉斯的冒险者已经征服了艾泽拉斯的大地及遥远的彼岸。他们在对抗世界上最致命的敌人时展现出过人的手腕,并且成功阻止终结宇宙等级的威胁。当他们在为即将于《魔兽世界》资料片《地心之战》中来袭的萨拉塔斯势力做战斗准备时,他们还需要在熟悉的阿拉希高地面对一个全新的敌人──那就是彼此。在《巨龙崛起》10.2.6 更新的《强袭风暴》中,玩家将会进入一个全新的海盗主题大逃杀式限时活动,其中包含极高的风险和史诗级的奖励。
《强袭风暴》不是普通的战场,作为一个独立于主游戏之外的活动,玩家可以用大逃杀的风格来体验《魔兽世界》,不分职业、不分装备(除了你在赛局中捡到的),光是技巧和战略的强弱之分就能决定出谁才是能坚持到最后的赢家。本次活动将会开放单人和双人模式,玩家在加入海盗主题的预赛大厅区域前,可以从强袭风暴角色画面新增好友。游玩游戏将可以累计名望轨迹,《巨龙崛起》和《魔兽世界:巫妖王之怒 经典版》的玩家都可以获得奖励。
更新日志
- 【雨果唱片】中国管弦乐《鹿回头》WAV
- APM亚流新世代《一起冒险》[FLAC/分轨][106.77MB]
- 崔健《飞狗》律冻文化[WAV+CUE][1.1G]
- 罗志祥《舞状元 (Explicit)》[320K/MP3][66.77MB]
- 尤雅.1997-幽雅精粹2CD【南方】【WAV+CUE】
- 张惠妹.2007-STAR(引进版)【EMI百代】【WAV+CUE】
- 群星.2008-LOVE情歌集VOL.8【正东】【WAV+CUE】
- 罗志祥《舞状元 (Explicit)》[FLAC/分轨][360.76MB]
- Tank《我不伟大,至少我能改变我。》[320K/MP3][160.41MB]
- Tank《我不伟大,至少我能改变我。》[FLAC/分轨][236.89MB]
- CD圣经推荐-夏韶声《谙2》SACD-ISO
- 钟镇涛-《百分百钟镇涛》首批限量版SACD-ISO
- 群星《继续微笑致敬许冠杰》[低速原抓WAV+CUE]
- 潘秀琼.2003-国语难忘金曲珍藏集【皇星全音】【WAV+CUE】
- 林东松.1997-2039玫瑰事件【宝丽金】【WAV+CUE】