MongoDB 索引

索引Indexes

索引常常用来大幅度的提升查询的性能。 考虑应用程序的查询种类是非常重要的事情，因此你就要定义相关的索引。

决定了之后，在MongoDB中创建索引是非常简单的。

基础

索引就是collection中一个document指定一个字段值的数据结构。MongoDB查询优化器可以使用这个数据结构快速分类整理以及排序document。一般来说，索引的实现是B-TREE。

在Shell中，你可以使用ensureIndex()来创建索引，并且指定要索引一个或多个字段。

我们在j字段上创建一个索引

db.things.ensureIndex({j:1});

如果索引不存在，ensureIndex就创建索引。

一旦索引被创建了，匹配索引字段的查询是非常快速的。

没有索引的话，MongoDB必须检查每个document要查询的字段。

db.things.find({j : 2}); // 快速，使用了索引。

db.things.find({x : 3});  // 慢- 检查所有的document，因为x没有被索引。

你可以使用db.things.getIndexes();来查看索引信息。

默认索引

_id字段默认被添加了索引。这个索引也不能被删除。_id索引是唯一的。Capped Collections并不会默认创建索引。

Embedded Keys

你甚至可以向embedded document的字段创建索引。例子

db.things.ensureIndex({"address.city": 1})

document做为key

索引的字段可以为任意类型，包括了document类型。

db.factories.insert( { name: "xyz", metro: { city: "New York", state: "NY" } } );

db.factories.ensureIndex( { metro : 1 } );

//这个查询可以使用上面创建的索引。

db.factories.find( { metro: { city: "New York", state: "NY" } } );

//等同于

db.factories.find( { metro: { $gte : { city: "New York" } } } );

//metro内的字段顺序错误，不能应用这个索引。

db.factories.find( { metro: { state: "NY" , city: "New York" } } );

也可以创建这个document内字段的组合索引。

db.factories.ensureIndex( { "metro.city" : 1, "metro.state" : 1 } );

//以下查询可以使用上面创建的索引。

db.factories.find( { "metro.city" : "New York", "metro.state" : "NY" } );

db.factories.find( { "metro.city" : "New York" } );

db.factories.find().sort( { "metro.city" : 1, "metro.state" : 1 } );

db.factories.find().sort( { "metro.city" : 1 } )

下面谈谈这两种方法的优劣势。

当使用整个document做为索引，顺序就默认定义了，升序。

当使用组合索引，你可以混合升序和降序的key，并且查询优化器使用该索引也需要匹配查询中的首个字段。

数组

当索引的键为数组的时候，MongoDB会索引数组中每个元素。

组合索引

除了支持单个字段的索引，MongoDB也支持索引多个字段。创建的索引地方法一样，都使用ensureIndex()。但是你可以指定多个字段。

db.things.ensureIndex({j:1, name:-1});

当创建索引的时候，上面的数字1和-1代表着索引的方向。1是升序，-1为降序。如果为单个索引，顺序并无所谓。如果使用组合索引，顺序就非常重要了。

你可以在多个字段创建索引，查询可以用字段子集做为开头来匹配索引。

如果你在a,b,c上创建索引。

下列查询都可以使用这个索引。

a

a,b

a,b,c

1.6+新特性 目前，可以组合索引中的字段条件可以为等值的组合或者范围查询。 如果索引中的首个字段存在于查询中，那么查询优化器可能会选用这个索引。 如果索引中的首个字段不存在于查询中，如果显式使用hint才可以使用这个索引。 索引的子集字段在查询中，这种索引可以用在很多地方。 做为一般的规则来说，对于指定的查询，最又索引就是那些要查询的字段。

Sparse Indexes稀疏索引

目前的限制 稀疏索引只能在一个字段上创建. SERVER-2193

1.7.4的新功能。

sparse index就是在一个存在于document的字段上创建的索引。
任何document中不存在这个索引的字段，那么就不会保存在索引中。之所以叫sparse，当没有索引字段的值的时候，document也就丢失了。

Sparse indexes, 不是完整的索引，也和完整索引操作上有所不同。当使用一个sparse index排序，一些document就不会返回了。

只有存在于index中的document才会返回。

db.people.ensureIndex({title : 1}, {sparse : true})

db.people.save({name:"Jim"})

db.people.save({name:"Sarah", title:"Princess"})

db.people.find({title:{$ne:null}}).sort({title:1}) 

// 只返回 Sarah的文档

你可以把sparse何unique索引结合起来，来给那些没有丢失字段的document加以唯一性约束。

 

Unique Indexes唯一索引

MongoDB支持唯一索引，保证了插入document的索引值和已存在document索引值不重复。

下面的示例就保证了不会有两个document中的firstname和lastname值相等。

db.things.ensureIndex({firstname: 1, lastname: 1}, {unique: true});

丢失的键

当保存一个不存在唯一索引的字段的document，那么这个字段的值默认为null。但是这种缺失索引字段的document只能插入一次了。

db.things.ensureIndex({firstname: 1}, {unique: true});  

db.things.save({lastname: "Smith"}); 

 /这个操作就会发生错误。 

db.things.save({lastname: "Jones"});

重复的值

一个唯一索引的值是不能重复的。

保存首个document，而要删除其他索引值和它重复的document，添加参数dropDups

db.things.ensureIndex({firstname : 1}, {unique : true, dropDups : true})

在后台创建索引

创建一个索引，默认的情况会阻塞其他数据库的操作。在1.3.2+版本，支持后台创建索引background index build option .

删除索引

删除指定collection的索引语句为

db.collection.dropIndexes();

删除一个单独的索引

db.collection.dropIndex({x: 1, y: -1})

直接运行一个命令

// 注意:1.3.2之前 命令是"deleteIndexes", 而不是 "dropIndexes"

// 从foo collection中删除 {y:1}索引

db.runCommand({dropIndexes:'foo', index : {y:1}})

// 删除所有索引

db.runCommand({dropIndexes:'foo', index : '*'})

重新索引

reIndex会重新创建索引

db.myCollection.reIndex()

// 等同于:

db.runCommand( { reIndex : 'myCollection' } )

一般来说用不上。如果collection大小增长太快或者索引占用空间看起来很大，就可以使用reIndex。

修复数据库会重新创建索引。

额外要注意的

• MongoDB 索引区分大小写。
• 当你更新u update 一个对象, 如果对象占用了之前分配的区域, 仅仅是那些更新值的索引需要更新，这样做提升了性能。注意如果对象增大并且需要迁移，那么所有的索引也需要更新，过程比较慢。
• 索引信息在system.indexes的collection中。Index 运行 db.system.indexes.find() 查看索引。

索引的性能

索引主要用于查询，也包括了排序，非常的快。通过索引查找的document更新也是非常快的。

然而，要记住的是，索引会降低插入和删除的性能。原因就是数据的写入也要同时也如索引。

但是索引对于那些读取多于写入的collection尤为有用。

对于写入数据频率高的collection，索引会影响性能。

大部分collection都是读取率高，所以索引对于大部分场景还是非常不错的。

不适用索引来进行排序

如果排序的数据非常少(小于4M)，那就不需要索引。一般要limit和sort一起使用。

Geospatial地理空间

• 查看Geospatial Indexing.