您现在的位置：首页 > 实用文 > 其他范文

mongodb学习(索引详解)

时间：2022-05-24 00:43:03 其他范文收藏本文下载本文

【导语】下面是小编整理的mongodb学习(索引详解)（共8篇），希望能帮助到大家!

mongodb学习(索引详解)

篇1：mongodb学习(索引详解)

接下来，我为persons集合的id键创建索引，在mongodb中为我们提供了一个方法：

db.集合名称.ensureIndex({需要创建索引的键：1或-1})

这里1表示建立升序的索引，-1表示建立降序的索引

在创建索引以后的时间变为几乎为0毫秒了，还是大大大的提高了查询效率

注意：使用索引可以提高我们的查询效率，可是会影响我们的插入和更改的效率，因为在插入和更改的时候是会维护该索引的，对于更新较少查询较多的集合可以使用索引。

查看索引

db.persons.getIndexes

可以看到这里有两个索引，一个是系统默认会创建一个”_id”索引，另外一个就是我们自己创建的”number_id”,可以看到这里的索引名称和我们的键值默认是相同的，如果我需要创建自己的索引名称，比如我为name创建一个叫做”personName”的索引，可以这样写：vcD4NCjxwcmUgY2xhc3M9”brush:sql;“>db.persons.ensureIndex({name:1},{name:”personName“})

现在，我们的persons集合中有三个索引了，可以看到第三个name索引的名称就是我们自己给的”personName”

篇2：mongodb学习(索引详解)

db.persons.ensureIndex({键:1或-1},{unique:true})

好了，已经为name键创建了一个降序的唯一索引，那么我们在试着插入一条name=”aName0”的记录

此时会插入失败，系统提示我们该name键已经创建了唯一索引

篇3：mongodb学习(索引详解)

如果我的集合中创建了好几个索引，我需要使用某一个索引，可以通过在find后面加上hint({索引名称：1或-1})，来实现使用指定的索引，

注意：指定的索引必须提前存在，不然会查询失败。

篇4：mongodb学习(索引详解)

删除单个索引

db.runCommand({dropIndexes:”集合名称“,index:”索引的键:1或-1“})

删除所有索引

db.runCommand({dropIndexes:”集合名称“,index:”索引的键:“*”})

关于索引的学习就到这里了。

篇5：mongodb学习(索引详解)

如果我们在创建唯一索引之前，在需要创建唯一索引的键上已经存在重复值。可以利用下面代码去除已经存在的重复值：

db.persons.ensureIndex({name:-1},{unique:true,dropDups:true})

篇6：MySQL 索引详解

一、单列索引和组合索引（也叫复合索引）的选择效率问题

先阐述下单列索引和组合索引的概念：

单列索引：即一个索引只包含单个列，一个表可以有多个单列索引，但这不是组合索引，

组合索引：即一个索包含多个列。

如果我们的查询where条件只有一个，我们完全可以用单列索引，这样的查询速度较快，索引也比较瘦身。如果我们的业务场景是需要经常查询多个组合列，不要试图分别基于单个列建立多个单列索引。这是因为当SQL语句所查询的列，全部都出现在复合索引中时，此时由于只需要查询索引块即可获得所有数据，当然比使用多个单列索引要快得多。下面以实际例子说明：

举例：

以下是代码片段：

CREATE TABLE people ( peopleid SMALLINT NOT NULL AUTO_INCREMENT, firstname CHAR(50) NOT NULL, lastname CHAR(50) NOT NULL, age SMALLINT NOT NULL, townid SMALLINT NOT NULL, PRIMARY KEY (peopleid) );

下面是我们插入到这个people表的数据：

这个数据片段中有四个名字为“Mikes”的人(其中两个姓Sullivans，两个姓McConnells)，有两个年龄为17岁的人，还有一个名字与众不同的Joe Smith。

这个表的主要用途是根据指定的用户姓、名以及年龄返回相应的peopleid。例如，我们可能需要查找姓名为Mike Sullivan、年龄17岁用户的peopleid(SQL命令为SELECT peopleid FROM people WHERE firstname=“Mike” AND lastname=“Sullivan” AND age=17;)。由于我们不想让MySQL每次执行查询就去扫描整个表，这里需要考虑运用索引。

首先，我们可以考虑在单个列上创建索引，比如firstname、lastname或者age列。如果我们创建firstname列的索引(ALTER TABLE people ADD INDEX firstname (firstname);)，MySQL将通过这个索引迅速把搜索范围限制到那些firstname=“Mike”的记录，然后再在这个“中间结果集”上进行其他条件的搜索：它首先排除那些lastname不等于“Sullivan”的记录，然后排除那些age不等于17的记录。当记录满足所有搜索条件之后，MySQL就返回最终的搜索结果。

由于建立了firstname列的索引，与执行表的完全扫描相比，MySQL的效率提高了很多，但我们要求MySQL扫描的记录数量仍旧远远超过了实际所需要的。虽然我们可以删除firstname列上的索引，再创建lastname或者age列的索引，但总地看来，不论在哪个列上创建索引搜索效率仍旧相似。

为了提高搜索效率，我们需要考虑运用多列索引。如果为firstname、lastname和age这三个列创建一个多列索引，MySQL只需一次检索就能够找出正确的结果!下面是创建这个多列索引的SQL命令：

以下是代码片段：

ALTER TABLE people ADD INDEX fname_lname_age (firstname,lastname,age);

由于索引文件以B+树格式保存，MySQL能够立即转到合适的firstname，然后再转到合适的lastname，最后转到合适的age。在没有扫描数据文件任何一个记录的情况下，MySQL就正确地找出了搜索的目标记录!

那么，如果在firstname、lastname、age这三个列上分别创建单列索引，效果是否和创建一个firstname、lastname、age的多列索引一样呢？答案是否定的，两者完全不同。当我们执行查询的时候，MySQL只能使用一个索引。如果你有三个单列的索引，MySQL会试图选择一个限制最严格的索引。但是，即使是限制最严格的单列索引，它的限制能力也肯定远远低于firstname、lastname、age这三个列上的多列索引。

二、谨防最左前缀索引失效问题

继续考虑前面的例子，现在我们有一个firstname、lastname、age列上的多列索引，我们称这个索引为fname_lname_age。它相当于我们创建了(firstname，lastname，age)、(firstname，lastname)以及(firstname)这些列组合上的索引。为什么没有 (lastname,age)等这样的组合索引呢？这是因为 mysql 组合索引“最左前缀”（Leftmost Prefixing）的结果。简单的理解就是只从最左面的开始组合。并不是只要包含这三列的查询都会用到该组合索引。

以下是代码片段：

The following queries can use theLeftmost Prefixingindex:

SELECT peopleid FROM people WHERE firstname=“Mike” AND lastname=“Sullivan” AND age=“17”;

SELECT peopleid FROM people WHERE firstname=“Mike” AND lastname=“Sullivan”;

SELECT peopleid FROM people WHERE firstname=“Mike”;

The following queries cannot use the Leftmost Prefixing index at all:

SELECT peopleid FROM people WHERE lastname=“Sullivan”;

SELECT peopleid FROM people WHERE age=“17”;

SELECT peopleid FROM people WHERE lastname=“Sullivan” AND age=“17”;

这里我特地实践了下：

执行结果如下：

可以看出这里最左前缀索引失效了。这里没有用到索引直接全表扫描了。

我们再看下如果这样呢？

执行结果如下：

可见还是用到了索引，不是应该失效吗？是不是有点迷糊了？

特地请教了DBA玄惭大师，这里只是最左前缀索引失效，但是不代表整个索引失效，只是效率没有那么高了。最左前缀索引的效率是比较高的。本来我误以为只要第一个查询字段不是组合索引的最左前缀索引字段整个索引会失效，其实不然。

这里强调下只是最有效率的最左前缀索引失效不是整个索引失效。

三、使用explain分析索引

在不确定应该在哪些数据列上创建索引的时候，我们可以从EXPLAIN SELECT命令那里往往可以获得一些帮助。这其实只是简单地给一条普通的SELECT命令加一个EXPLAIN关键字作为前缀而已。有了这个关键字，MySQL将不是去执行那条SELECT命令，而是去对它进行分析。MySQL将以表格的形式把查询的执行过程和用到的索引(如果有的话)等信息列出来。这里我基本阐述下每个信息字段含义，不展开阐述，我们只要注意几个关键点（关键点以下用红色加粗显示）能大概看懂即可呵呵~~

1.id:SQL执行的顺利的标识。

sql从里向外执行，通过以上观察发现sql是按照id从大到小执行的，

2.select_type:SELECT类型

1)简单SELECT(不使用UNION或子查询等)

2)PRIMARY：最外层的select

3）DERIVED：派生表的SELECT(FROM子句的子查询)

4）UNION：UNION中的第二个或后面的SELECT语句

5）UNION RESULT：UNION的结果。

6）DEPENDENT UNION：UNION中的第二个或后面的SELECT语句，取决于外面的查询

7）SUBQUERY：子查询中的第一个SELECT

8）DEPENDENT SUBQUERY：子查询中的第一个SELECT，取决于外面的查询

PS:这里我总结了下子查询的in语句会用到DEPENDENT关键字，如果子查询是union则是DEPENDENT UNION；如果子查询是简单的条件语句则是DEPENDENT SUBQUERY。这里不一定准确是我自己总结的哈~~如果不对望指正

3.table：表的名字。

有时不是真实的表名字,看到的是derivedx(x是个数字,我的理解是第几步执行的结果)

4.type：连接操作的类型。

这列很重要,显示了连接使用了哪种类别,有无使用索引。在各种类型的关联关系当中，效率最高的是system，然后依次是const、eq_ref、ref、range、index和 All。一般来说，得保证查询至少达到range级别，最好能达到ref，否则就可能会出现性能问题。

1）system

表只有一行：system表。这是const连接类型的特殊情况

2）const

表中的一个记录的最大值能够匹配这个查询（索引可以是主键或惟一索引）。因为只有一行，这个值实际就是常数，因为MYSQL先读这个值然后把它当做常数来对待

3）eq_ref

在连接中，MYSQL在查询时，从前面的表中，对每一个记录的联合都从表中读取一个记录，它在查询使用了索引为主键或惟一键的全部时使用

4）ref

这个连接类型只有在查询使用了不是惟一或主键的键或者是这些类型的部分（比如，利用最左边前缀）时发生。对于之前的表的每一个行联合，全部记录都将从表中读出。这个类型严重依赖于根据索引匹配的记录多少（越少越好）

5）range

这个连接类型使用索引返回一个范围中的行，比如使用>或<查找东西时发生的情况>

6）index

这个连接类型对前面的表中的每一个记录联合进行完全扫描（比ALL更好，因为索引一般小于表数据）

7）ALL

这个连接类型对于前面的每一个记录联合进行完全扫描，这一般比较糟糕，应该尽量避免。因为它要扫描整个表。你可以加入更多的索引来解决这个问题。

5.possible_keys：MySQL在搜索数据记录时可以选用的各个索引的名字。

这里的索引名字是创建索引时指定的索引昵称;如果索引没有昵称，则默认显示的是索引中第一个列的名字(在上一节举的例子中是“firstname”)。默认索引名字的含义往往不是很明显。

6.key：它显示了MySQL实际使用的索引的名字。

key数据列是MySQL实际选用的索引，如果它为空(或NULL)，则MySQL不使用索引。

7.key_len：索引中被使用部分的长度，以字节计。

key_len的值可以告诉你在联合索引中mysql会真正使用了哪些索引。在上例中，key_len是102，其中firstname占50字节，lastname占50字节，age占2字节（smallint存储大小为2字节）。如果MySQL只使用索引中的firstname部分，则key_len将是50。在不损失精确性的情况下，key_len数据列里的值越小越好(意思是更快)。

8.ref：显示使用哪个列或常数与key一起从表中选择行。

ref数据列给出了关联关系中另一个数据表里的数据列的名字。

9.rows：MySQL所认为的它在找到正确的结果之前必须扫描的记录数。

显然，这里最理想的数字就是1。

10.extra：附加信息

Using index和Using where会遇到的比较多，可以重点记下，其他的我没怎么遇到过了解即可，遇到具体问题可以查阅哈

1）Distinct

一旦MYSQL找到了与行相联合匹配的行，就不再搜索了

2）Not exists

MYSQL优化了LEFT JOIN，一旦它找到了匹配LEFT JOIN标准的行，就不再搜索了

3）Range checked for each

没有找到理想的索引，因此对于从前面表中来的每一个行组合，MYSQL检查使用哪个索引，并用它来从表中返回行。这是使用索引的最慢的连接之一

4）Using filesort

看到这个的时候，查询就需要优化了。MYSQL需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行

5）Using index

列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的，这发生在对表的全部的请求列都是同一个索引的部分的时候

6）Using temporary

看到这个的时候，查询需要优化了。这里，MYSQL需要创建一个临时表来存储结果，这通常发生在对不同的列集进行ORDER BY上，而不是GROUP BY上

7）Using where

使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。如果不想返回表中的全部行，并且连接类型ALL或index，这就会发生，或者是查询有问题

先说到这，下面一篇给大家总结下如何选择索引列以及使用索引的注意事项。

REF：

www.taobaotest.com/blogs/2395

www.taobaotest.com/blogs/2410

MySQL索引分析和优化

MySQL EXPLAIN 详解

篇7：关于mongodb创建索引的一些经验总结

想来接触mongodb已经快一年了，对于它的索引知识也积攒了不少经验，趁着这个月黑风高的夜晚，就把mongodb的索引总结一番吧，

一，索引介绍

mongodb具有两类索引，分别为单键索引和复合索引。

1.单键索引是最简单的一种索引，创建单键索引的开销要比复合索引小很多。单键索引主要用于针对单值查询的条件。

2.复合索引是将文档中的几个键联合起来创建的一种索引，创建这种索引需要更多的空间与性能开销。分别体现在：

1).在给大量数据创建复合索引时，会阻塞数据库的查询，更不用说修改和插入操作了；

2).插入一条数据时，要花费更多的时间来给复合索引加数据；

3).创建的复合索引所站得空间大小根据数据的类型以及键的数量而有所不同。比如，如果你用五个NumberInt的键创建的复合索引的空间大小，并不会比两个NumberInt和一个String类型创建的复合索引占用更多的空间。索引在设计数据类型时，尽量将数据类型设置为NumberInt类型，以及尽量少使用string类型的数据做索引；

二，创建索引

创建索引的语句很简单。

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”

}

篇8：详解SQL Server数据库索引

一、理解索引的结构

索引在数据库中的作用类似于目录在书籍中的作用，用来提高查找信息的速度，使用索引查找数据，无需对整表进行扫描，可以快速找到所需数据。微软的SQL SERVER提供了两种索引：聚集索引(clustered index，也称聚类索引、簇集索引)和非聚集索引(nonclustered index，也称非聚类索引、非簇集索引)。

SQL Server 中数据存储的基本单位是页(Page)。数据库中的数据文件(.mdf 或 .ndf)分配的磁盘空间可以从逻辑上划分成页(从 0 到 n 连续编号)。磁盘 I/O 操作在页级执行。也就是说，SQL Server 每次读取或写入数据的最少数据单位是数据页。

下面我们先简单的了解一下索引的体系结构：

1. 聚集索引结构

在 SQL Server 中，索引是按 B 树结构进行组织的。

聚集索引单个分区中的结构:

--建立UserAddDate聚集索引

CREATE CLUSTERED INDEX [IX_UserAddDate] ON [ASPNet_zSurvey].[ZS_User]

(

[UserAddDate] ASC

)

聚集索引(Clustered Index)特点

聚集索引的叶节点就是实际的数据页

聚集索引中的排序顺序仅仅表示数据页链在逻辑上是有序的。而不是按照顺序物理的存储在磁盘上

行的物理位置和行在索引中的位置是相同的

每个表只能有一个聚集索引

聚集索引的平均大小大约为表大小的5%左右

2.非聚集索引结构

非聚集索引与聚集索引具有相同的 B 树结构，它们之间的显著差别在于以下两点：

1. 基础表的数据行不按非聚集键的顺序排序和存储。

2. 非聚集索引的叶层是由索引页而不是由数据页组成。

下图示意了单个分区中的非聚集索引结构：

包含列的索引

通过将包含列(称为非键列)添加到索引的叶级，可以扩展非聚集索引的功能。键列存储在非聚集索引的所有级别，而非键列仅存储在叶级别。

下面举个简单的例子来说明一下聚集索引和非聚集索引的区别：

我们有一本汉语字典，可以把它的正文本身看做是一个聚集索引，它是按照汉字拼音的开头字母排序的，不再需要查找其他目录。当遇到不认识的字时，需要结合“部首目录”和“检字表”，先找到目录中的结果，然后再翻到您所需要的页码。通过这种方法查到的目录中字的排序并不是真正的正文的排序方法。把这种看做是一个非聚集索引。

另外，请注意每个表只能有一个聚集索引。

--建立UserAddDate非聚集索引

CREATE NONCLUSTERED INDEX [IX_UserAddDate] ON [ASPNet_zSurvey].[ZS_User]

(

[UserAddDate] ASC

)

非聚集索引 (Unclustered Index) 特点

非聚集索引的页，不是数据，而是指向数据页的页。

若未指定索引类型，则默认为非聚集索引

叶节点页的次序和表的物理存储次序不同

每个表最多可以有249个非聚集索引

在非聚集索引创建之前创建聚集索引(否则会引发索引重建)

二、选择建立哪种索引

1.何时创建聚集索引更能提高性能

Clustered Index会提高大多数table的性能，尤其是当它满足以下条件时：

独特, 狭窄, 持续增长的，最好是只向上增加，

例如：

•Identity

•Date, identity

•GUID (only when using newsequentialid() function)

2.非聚集索引提高性能的方法

非聚集索引由于B树的节点不是具体数据页，有时候由于这个原因，会导致非聚集索引甚至不如表遍历来的快。但是，非聚集索引有个特性，如果你要查询的内容，在非聚集索引中以及被覆盖到了，则不需要继续到聚集索引，或者RID(heap结构中的行标识符)中去寻找数据了，这时候就可以很大的提高性能，这就是覆盖面(Covering) 的问题。

由于聚集索引叶子节点就是具体数据，所以聚集索引的覆盖率是 100%，通过提高覆盖面来提高性能的问题也就只有非聚集索引(Nonclustered Indexes)才存在。

当查询中所有的columns 都包括在index上时，我们说这个 index covers the query. Columns的顺序在此不重要(Select 时候的顺序不重要,但是Index 建立的顺序可得小心了)。

在 SQL Server 2005 中，为了提高这种 Covering 带来的好处，甚至可以通过将非键列添加到非聚集索引的叶级别来扩展非聚集索引的功能。

补充：只有查询在具有高度选择性的情况下，非聚集索引才有优势。

三、使用聚集索引或非聚集索引的场景 (注：优先级依次为推荐，应，不应)

四、主键和聚集索引的比较

以下是一些大众点评网中测试使用的示例：

CHECKPOINT

DBCC DROPCLEANBUFFERS

SET STATISTICS IO ON

declare @d datetime

set @d=getdate()