MongoDB数据库索引

约定不等于承诺〃 2021-12-23 08:43 266阅读 0赞

## 前面的话 ##

索引通常能够极大的提高查询的效率，如果没有索引，MongoDB在读取数据时必须扫描集合中的每个文件并选取那些符合查询条件的记录。这种扫描全集合的查询效率是非常低的，特别在处理大量的数据时，查询可以要花费几十秒甚至几分钟，这对网站的性能是非常致命的。本文将详细介绍MongoDB数据库索引

### 引入 ###

索引能够提高查询效率，如何体现呢？接下来使用性能分析函数explain()来进行分析说明

首先，插入10万条数据

![740839-20170718114105458-1821673395.png][]

接着，不创建索引，来寻找time范围在100和200之间的文档

![740839-20170718130715818-833120556.png][]

由图中所知，totalDocsExamined值为100000，表示查找了100000个文档；nReturned值为101，表示返回了101个文档；executionTimeMillis值为39，表示花费了39ms

下面，我们在time字段上建立索引

![740839-20170718131115552-1849538615.png][]

再次，寻找time范围在100和200之间的文档

![740839-20170718131213490-346607119.png][]

由图可知，totalDocsExamined和nReturned值都是101，executionTimeMillis值为0，相当于从101个文档中，找到了101个文档，查找的速度趋近于0。由此可见，使用索引极大地提升了查询速度

### 概述 ###

索引是特殊的数据结构，以易于遍历的形式存储数据集的一小部分。 索引存储特定字段或一组字段的值，按照索引中指定的字段值排序

使用索引，可以加快索引相关的查询，也相应地带来一些坏处

1、增加磁盘空间的消耗。在索引比较多的情况下，索引文件所占据的空间有可能超过数据本身

2、在写入数据或更新数据时，对索引的维护一般是写之外的另一条逻辑，一定程度上，会降低写入性能

但是，为了查询的高效，这些影响是值得的。有很多情况下，系统的性能下降，与不合理的索引创建有关。所以，合理的创建索引，可以减少索引带来的不好的影响

### 索引设置 ###

【getIndexes()】

使用getIndexes()方法来查询索引

db.collection_name.getIndexes()

由下图可知，有"\_id"和"time"两个索引

![740839-20170718132616818-1498984853.png][]

【createIndex()】

db.COLLECTION_NAME.createIndex({KEY:1})

语法中Key值为要创建的索引字段，1为指定按升序创建索引，如果想按降序来创建索引指定为-1即可

![740839-20170718131115552-1849538615.png][]

当然，也可以创建多个索引字段

db.COLLECTION_NAME.createIndex({k1:1,k2:1})

在MongoDB3.0版本之前，使用的是ensureIndex()方法，现在ensureIndex()方法依然可以使用，只是createIndex()方法的别名

如果文档较多，创建索引需要耗费一定的时间。如果系统负载较重，且有很多已经存在的文档，不能直接使用这个命令进行创建，需要在使用数据库之前，就将索引创建完毕。否则，严重影响数据库的性能

\[注意\]索引可以重复创建，如果对已经存在的索引再次创建，会直接返回成功

![740839-20170718134551771-706636260.png][]

createIndex() 接收可选参数，可选参数列表如下：

Parameter     Type    　　Description
    background    Boolean    建索引过程会阻塞其它数据库操作，background可指定以后台方式创建索引，默认值为false
    unique        Boolean    建立的索引是否唯一。指定为true创建唯一索引。默认值为false
    name          string     索引的名称。如果未指定，MongoDB通过连接索引的字段名和排序顺序生成一个索引名称
    dropDups      Boolean    在建立唯一索引时是否删除重复记录,指定 true 创建唯一索引。默认值为 false
    sparse        Boolean    对文档中不存在的字段数据不启用索引；如果设置为true，索引字段中不会查询出不包含对应字段的文档。默认值为false
    v             index version    索引的版本号。默认的索引版本取决于mongod创建索引时运行的版本
    weights       document   索引权重值，数值在 1 到 99,999 之间，表示该索引相对于其他索引字段的得分权重
    expireAfterSeconds  integer   指定一个以秒为单位的数值，完成 TTL设定，设定集合的生存时间
    default_language    string    对于文本索引，该参数决定了停用词及词干和词器的规则的列表。 默认为英语
    language_override   string    对于文本索引，该参数指定了包含在文档中的字段名，默认值为language

db.db_coll1.createIndex({time:1},{background:true})

【dropIndex()】

使用db.collection\_name.dropIndex(\{key:1\})方法可以删除指定索引

db.collection_name.dropIndex({key:1})

![740839-20170718143349740-1820668762.png][]

\[注意\]\_id索引无法被删除

![740839-20170718143620708-1791891668.png][]

除了使用键值对来删除索引，还可以使用其name值来删除索引

如下所示，\{time:1\}的name值为"time\_1"，使用db.db\_coll1.dropIndex("time\_1")也可以删除索引

![740839-20170718175322146-1486858365.png][]

【dropIndexes()】

使用db.collection\_name.dropIndexes()方法可以删除所有索引

db.collection_name.dropIndexes()

![740839-20170718143652490-701609368.png][]

### 索引属性 ###

【TTL】

过期索引又称为TTL索引，是一种特殊类型的单字段索引，主要用于当满足某个特定时间之后自动删除相应的文档。也就是说集合中的文档有一定的有效期，超过有效期的文档就会失效，会被移除。也即是数据会过期。过期的数据无需保留，这种情形适用于如机器生成的事件数据，日志和会话信息等等

同样地，过期索引使用createIndex()方法来创建，但它支持第二个参数expireAfterSeconds，用来指定多少秒过期或者包含过期日期值的数组

db.eventlog.createIndex( { x: 1 }, { expireAfterSeconds: 3600 } )

以下示例中，在60s后，会删除time文档

![740839-20170718173056536-2028675860.png][]

使用过期索引，有以下几点注意事项

1、存储在过期索引字段的值必须是指定的时间类型。必须是ISODate或者ISODate数组，不能使用时间戳，否则不能被自动删除

以下示例中time设置了ISODate类型的值，该值到60s后会被自动删除

![740839-20170718172843474-1538103345.png][]

以下示例中，time设置了时间戳，该值到60s后无法被删除

![740839-20170718173402755-969106420.png][]

2、如果指定了ISODate时间数组，则按照最小的时间进行删除

3、过期索引不能是复合索引

4、删除时间是不精确的。删除过程是由后台程序每60s跑一次，而且删除也需要一些时间，存在误差。所以，如果设置的到期时间与当前时间的间隔小于60s，则文档最少也要60s才能被删除

【唯一性】

索引的属性可以具有唯一性，即唯一索引，只要设置索引属性中的unique为true即可，默认为false。唯一索引用于确保索引字段不存储重复的值，即强制索引字段的唯一性。缺省情况下，mongodb的\_id字段在创建集合的时候会自动创建一个唯一索引

db.collection_name.createIndex({},{unique:true})

如下图所示，在默认情况下，不是唯一索引

![740839-20170718213834552-223482286.png][]

在设置unique:true后，不能插入重复的值

![740839-20170718214800130-1908206979.png][]

**常见错误**

如下图所示，设置的a字段为唯一索引，b字段也无法输入重复的值。这是因为设置a字段为唯一索引，插入数据b:10，相当于a:null，再插入b:10时，相当于又插入了a:null。而a:null和a:null是重复的，而a字段是唯一索引，无法重复。所以，无法插入重复的b:10

![740839-20170718214923349-1417226964.png][]

【稀疏性】

索引的属性可以具有稀疏性，即稀疏索引，只要设置索引属性中的sparse为true即可，默认为false

db.collection_name.createIndex({},{sparse:true})

稀疏性的不同代表了MongoDB在处理索引中存在但文档中不存在的字段的两种不同的方法

稀疏索引，也称为间隙索引就是创建索引的索引列在某些文档上列不存在，导致索引存在间隙。

假设，在一个集合中，创建了x字段上的索引。但是，插入的文档中并不包含x字段。在默认情况下，MongoDB依然会为这条不存在的字段创建索引。如果把这条索引创建为稀疏索引，则这条索引将不会被使用

如果数据集合中很多文档在创建索引的字段上并没有值，使用稀疏索引可以减少磁盘占用，且提高插入速度

**$exits**

使用稀疏索引时，可能会带来一些隐患。MongoDB提供了一种$exits操作符，$exits表示字段是否存在

![740839-20170718230258568-451259424.png][]

由下图所示，创建了\{m:1\}的稀疏索引，使用find()方法查找不存在m字段的文档时，结果出现了。是因为，MongoDB并没有使用稀疏索引来查询

如果使用hint()方法强制使用稀疏索引来查找索引上存在而文档中不存在的字段，则没有结果。再次说明稀疏索引不能用来查找索引上存在，但文档里不存在的字段

![740839-20170718230542036-521185838.png][]

### 索引种类 ###

MongoDB支持基于集合文档上任意列创建索引。缺省情况下，所有的文档的\_id列上都存在一个索引。基于业务的需要，可以基于一些重要的查询和操作来创建一些额外的索引。这些索引可以是单列，也可是多列(复合索引)，多键索引，地理空间索引，全文索引等

MongoDB支持6种索引，包括

1、\_id索引

2、单键索引

3、多键索引

4、复合索引

5、全文索引

6、地理位置索引

【\_id索引】

\_id索引是绝大多数集合默认建立的索引，对于每个插入的数据，MongDB都会自动生成一条唯一的\_id字段

由下图所示，在未插入任何索引之前，已经存在\_id索引

![740839-20170718143806443-486817012.png][]

【单键索引】

单键索引是最普通的索引，与\_id索引不同，单键索引不会自动创建

比如，一条记录，形式为\{x:1,y:2,z:3\}，在x字段上建立索引，之后就可以使用x为条件进行查询

![740839-20170718144349818-964190882.png][]

【多键索引】

在MongoDB中可以基于数组来创建索引。mongodb为数组每一个元素创建索引值。多键索引支持数组字段的高效查询。多键索引能够基于字符串，数字数组以及嵌套文档进行创建

多键索引与单键索引创建形式相同，区别在于字段的值。单键索引的值为单一的值，如一个字符串、数字或日期。多键索引的值具有多个记录，如一个数组

如果mongoDB中插入数组类型的多键数据，索引是自动建立的，无需刻意指定。但是，使用getIndexes()方法并没有多键索引，除非显式地创建多键索引

【复合索引】

MongoDB支持复合索引，即将多个键组合到一起创建索引。该方式称为复合索引，或者也叫组合索引，该方式能够满足多键值匹配查询使用索引的情形。其次复合索引在使用的时候，也可以通过前缀法来使用索引

\[注意\]任意复合索引字段不能超过31个

比如，插入\{x:1,y:2,z:3\}的记录，当需要按照x与y的值进行查询时，就需要创建x与y的复合索引。接着，就可以使用x和y作为条件进行查询

db.db_coll1.createIndex({x:1,y:1})
    db.db_coll1.createIndex({x:-1,y:1})
    db.db_coll1.createIndex({x:-1,y:-1})
    db.db_coll1.createIndex({x:1,y:-1})
    db.db_coll1.createIndex({y:1,x:1})
    db.db_coll1.createIndex({y:-1,x:1})
    db.db_coll1.createIndex({y:-1,x:-1})
    db.db_coll1.createIndex({y:1,x:-1})

复合索引创建时按升序或降序来指定其排列方式。对于单键索引，其顺序并不是特别重要，因为MongoDB可以在任一方向遍历索引。对于复合索引，按何种方式排序能够决定该索引在查询中能否被使用到

x与y的复合索引共包括以上8种情况，x和y的先后次序不同，升序或降序不同 ，都会产生不同的索引。而查询优化器，会使用我们建立的这些索引来创建查询方案，最终选择出最优的索引来查询数据

索引前缀指的是复合索引的子集

假如存在如下索引

{ "item": 1, "location": 1, "stock": 1 }

那存在下列索引前缀

{ item: 1 }
    { item: 1, location: 1 }

在MongoDB中，下列查询过滤条件情形中，索引将会被使用到

item字段
    item字段 + location字段
    item字段 + location字段 + stock字段
    item字段 + stock字段(尽管索引被使用，但不高效)

以下过滤条件查询情形，索引将不会被使用到

location字段
    stock字段
    location + stock字段

### 全文索引 ###

【创建】

全文索引也叫做文本索引，常见于搜索框中。我们在搜索框中输入关键词，比如 "HTML"，不仅标题中带有"HTML"的文章会被搜索出来，而且文章中存在"HTML"的文章也会被搜索出来

为了索引一个存储字符串或者字符串数组的键，需要在创建选项中包含这个键并指定为 "text" ，如下：

db.reviews.createIndex( { comments: "text" } )

如果需要在多个字段上创建全文索引，则可以复合索引

db.reviews.createIndex(
       {
         subject: "text",
         comments: "text"
       }
     )

如果需要对所有字段创建全文索引，则需要使用$xx标识

db.collection_name.createIndex( { "$**": "text" } )

\[注意\]一个集合最多只能创建 一个 文本 索引

【使用】

如果使用全文索引进行搜索，则需要使用如下格式

db.collection_name.find({$text:{$search: '...'}})

假设使用如下的数据结构来存储一个完整的文章，author存储作者，title存储标题，article存储文章内容

{author:"",title:"",article:""}

现在来添加一些数据，并对所有字段创建全文索引

![740839-20170718192353911-2052122623.png][]

下面来搜索'huochai'，可搜索到3条记录

![740839-20170718192621958-2005168406.png][]

如果搜索'a2'，则只能搜索到第2条记录

![740839-20170718192719583-1990124348.png][]

如果搜索'a1 a2 a3'，则相当于或的关系，a1 或 a2 或 a3，可以搜索到3条记录

![740839-20170718192839943-545649125.png][]

如果搜索'huochai -css'，相当于查找包含'huochai'，但不包含'css'的记录，包括第1和第3条

![740839-20170718193158396-1654378045.png][]

如果要搜索且关系，比如同时包含huochai和css的记录，则需要在内部添加引号，" \\"huochai\\" \\"css\\" "

\[注意\]只支持双引号

![740839-20170718193601818-444512070.png][]

【相似度】

全文索引有一个相似度的概念，表示全文索引的搜索条件与记录的内容有多么相似

在find()方法的第二个参数中，score是一个数字，该数字越大，表示相似度越高

db.collection_name.find({$text:{$search: '...'}},{score:{$meta:"textScore"}})

现在，再插入一条内容，作者为'huochai'

![740839-20170718194759740-2019961370.png][]

然后开始搜索'huochai'，并带有相似度

![740839-20170718194836208-2074722309.png][]

下面使用相似度排序，相似度高的排在前面

sort({score:{$meta:"textScore"}})

![740839-20170718195038958-961812350.png][]

【限制】

1、每次查询，只能指定一个$text查询

2、$text查询不能出现在$nor查询中

3、查询中如果包含了$text，hint()将不再起作用

4、只能对整个单词查询，不能对单词的截取部分查询。类似地，中文做全文查询的时候，只能查询一段话中有空格的该字或者词

### 地理位置索引 ###

一般地，地理位置索引可以实现诸如按距离排序的餐馆、在某区域内的店铺筛选等

可以将一些点的位置存储在MongoDB中，创建地理位置索引索引后，可以按照位置来查找其他点。地理位置索引可以分为两种：一种是2d索引，用于存储和查找平面上的点；另一种是2dsphere索引，用于存储和查找球面上的点

查找方式一般有两种：一种是查找距离某个点一定范围内的点；另一种是查找包含在某区域内的点

【2D索引】

2D索引的创建方式如下

db.<collection>.createIndex( { <location field> : "2d" , <additional field> : <value> } , { <index-specification options> } )

options包括如下参数

{ min : <lower bound> , max : <upper bound> , bits : <bit precision> }

![740839-20170719121101677-1440233238.png][]

在mongodb中使用经纬度表示位置，\[经度， 纬度\]。经度范围在\[-180,180\]，纬度范围在\[-90,90\]

\[注意\]默认边界允许插入大于90或小于-90的不合理纬度值的文档。而对于这样不合理的点的地理查询，数据库行为是不可预知的。所以，尽量避免插入超出范围的维度值

![740839-20170719121142755-1346637104.png][]

2D索引的查询方式有三种，包括$near、$geoNear、$geoWithin

一种是使用$near查询，即查询距离某个点最近的点，默认返回100个

db.<collection>.find( { <location field> :{ $near : [ <x> , <y> ] } } )

![740839-20170719121301052-50854878.png][]

$maxDistance可以设置离当前点最远的距离

![740839-20170719121518193-902570436.png][]

$minDistance可以设置离当前点最近的距离

![740839-20170719121633708-1487356984.png][]

另一种是使用$geoNear查询，$geoNear使用runCommand命令进行使用

db.runCommand({geoNear:<collection_name>,near:[x,y],minDistance:..,maxDistance:..,num:...})

![740839-20170719123420224-1244622300.png][]

另一种是使用$geoWithin查询，即查询某个形状内的点

在mongodb中，有三种形状，包括矩形、圆形和多边形，使用方法如下

db.<collection>.find( { <location field> :{ $geoWithin :{ $box|$polygon|$center : <coordinates>} } } )

第一种是矩形，使用$box表示

｛$box:[[x1,y1],[x2,y2]]｝

![740839-20170719122326036-1466493946.png][]

第二种是圆形，使用$center表示

{$center:[[<x1>,<y1>],r]}

![740839-20170719122508646-1115302350.png][]

第三种是多边形，使用$polygon表示

{$polygon:[[<x1>,<y1>],[<x2>,<y2>],[<x3>,<y3>],...]}

![740839-20170719122559974-511777890.png][]

【2dsphere索引】

2dsphere索引的创建方式如下

db.collection_name.createIndex({a:"2dsphere"})

位置表示方式不再是简单的经纬度，而是一种GeoJSON的表示方式，用来描述一个点、一条直线、多边形等形状，格式如下

{type:"",coordinates:[<coordinates>]}

转载于:https://www.cnblogs.com/xiaohuochai/p/7198461.html

[740839-20170718114105458-1821673395.png]: /images/20211223/cd9dc839b90d472b82ba503d7072d86e.png
[740839-20170718130715818-833120556.png]: /images/20211223/2215587ab88d4e088bb1eb2177675973.png
[740839-20170718131115552-1849538615.png]: /images/20211223/141ec36e2cf841a09a64a342ce40eb4a.png
[740839-20170718131213490-346607119.png]: /images/20211223/f39e02b67eaa4ea4bcf99aea58b280e2.png
[740839-20170718132616818-1498984853.png]: /images/20211223/f599a1afc971425fa945242ad084e601.png
[740839-20170718134551771-706636260.png]: /images/20211223/2f7270d85da94c0abb69d84dd1499f22.png
[740839-20170718143349740-1820668762.png]: /images/20211223/b4e314456f984c9e8167315b5b83f9fb.png
[740839-20170718143620708-1791891668.png]: /images/20211223/dbf5528ef76847efaa0f027686f1465b.png
[740839-20170718175322146-1486858365.png]: /images/20211223/6c1edb172ad94e32a94474f4ec2498ef.png
[740839-20170718143652490-701609368.png]: /images/20211223/8eaf017091d04bb980fcb43735c8a34c.png
[740839-20170718173056536-2028675860.png]: /images/20211223/010f0b3ca1c34919bc5c698f04234b00.png
[740839-20170718172843474-1538103345.png]: /images/20211223/914d2f9c6af14883b1780fff9afa3c1f.png
[740839-20170718173402755-969106420.png]: /images/20211223/66d1b3ad66ce4d85a3abd52961281e30.png
[740839-20170718213834552-223482286.png]: /images/20211223/b8ee877e121f4fb1868ee42b0ea0ebe1.png
[740839-20170718214800130-1908206979.png]: /images/20211223/c8cf36dcc59547e0b60fac046927e1a5.png
[740839-20170718214923349-1417226964.png]: /images/20211223/2d30e6d1895f4154baf35dba9850e343.png
[740839-20170718230258568-451259424.png]: /images/20211223/9b7acfc83210413a8841e3bd4a4e7cfe.png
[740839-20170718230542036-521185838.png]: /images/20211223/04bb15d753e743fe868edc710888bcb4.png
[740839-20170718143806443-486817012.png]: /images/20211223/53f235660d7d4d87bfa150dab9bea627.png
[740839-20170718144349818-964190882.png]: /images/20211223/d5f46183b93747d688205e9f0b95d78d.png
[740839-20170718192353911-2052122623.png]: /images/20211223/13ae5d5099c04fcd8b70a0fa31c43683.png
[740839-20170718192621958-2005168406.png]: /images/20211223/c3d02087ba134dbc94867823c94d772d.png
[740839-20170718192719583-1990124348.png]: /images/20211223/1eb1924dcc59489190e72ac8a87e96ed.png
[740839-20170718192839943-545649125.png]: /images/20211223/420d98a262a641d5bd69908ce69e5e18.png
[740839-20170718193158396-1654378045.png]: /images/20211223/8d2301ac761f444cadf5c793f840d1ac.png
[740839-20170718193601818-444512070.png]: /images/20211223/1c48c7a2441d4c58951504f89205aa3f.png
[740839-20170718194759740-2019961370.png]: /images/20211223/2758373d6b3b422a984bf628ad3696bb.png
[740839-20170718194836208-2074722309.png]: /images/20211223/fd91210ecd834a968e9008acfe9d8493.png
[740839-20170718195038958-961812350.png]: /images/20211223/bfa6d181682c4ef89040ef2dee7dc8a5.png
[740839-20170719121101677-1440233238.png]: /images/20211223/e6f3a5551257489abc1e0d9a183fcdcd.png
[740839-20170719121142755-1346637104.png]: /images/20211223/2dc90a66a01e412296319d6a104ecee5.png
[740839-20170719121301052-50854878.png]: /images/20211223/c4d7044663ca4cddb814f75e99f36605.png
[740839-20170719121518193-902570436.png]: /images/20211223/8797aa68290346d1bba4f0a3a15f9fde.png
[740839-20170719121633708-1487356984.png]: /images/20211223/1816a1f73fee423e9426c2b93789ac59.png
[740839-20170719123420224-1244622300.png]: /images/20211223/5a9fa829ccaa425f8a644178195857fe.png
[740839-20170719122326036-1466493946.png]: /images/20211223/a0c3a4d5cb204804a3b31f2497300b1b.png
[740839-20170719122508646-1115302350.png]: /images/20211223/4a5bb3bde9ac4907876c56c7dac3b8eb.png
[740839-20170719122559974-511777890.png]: /images/20211223/4dbd058578b04a0398255b5baa37b914.png