数据库学习篇之数据库索引基本概念

索引的定义

        索引是为了加速对表中数据行的检索而创建的一种分散的存储结构。索引是针对表而建立的，它是由数据页面以外的索引页面组成的，每个索引页面中的行都会含有逻辑指针，以便加速检索物理数据。

        数据库索引是数据库管理系统中一个排序的数据结构，以协助快速查询，更新数据库中表的数据。索引的实现通常使用B树和变种的B+树(mysql常用的索引就是B+树)。除了数据之外，数据库系统还维护为满足特定查找算法的数据结构，这些数据结构以某种方式引用数据，这种数据结构就是索引。

　　在数据库关系图中，可以在选定表的“索引/键”属性页中创建、编辑或删除每个索引类型。当保存索引所附加到的表，或保存该表所在的关系图时，索引将保存在数据库中。
　　在关系数据库中，索引是一种单独的、物理的对数据库表中一列或多列的值进行排序的一种存储结构，它是某个表中一列或若干列值的集合和相应的指向表中物理标识这些值的数据页的逻辑指针清单。简单来讲：索引的作用相当于图书的目录，可以根据目录中的页码快速找到所需的内容。
　　索引提供指向存储在表的指定列中的数据值的指针，然后根据指定的排序顺序对这些指针排序。数据库使用索引以找到特定值，然后顺指针找到包含该值的行。这样可以使对应于表的SQL语句执行得更快，可快速访问数据库表中的特定信息。

　　当表中有大量记录时，若要对表进行查询，第一种搜索信息方式是全表搜索，是将所有记录一一取出，和查询条件进行一一对比，然后返回满足条件的记录，这样做会消耗大量数据库系统时间，并造成大量磁盘I/O操作；第二种就是在表中建立索引，然后在索引中找到符合查询条件的索引值，最后通过保存在索引中的ROWID（相当于页码）快速找到表中对应的记录。

索引的种类

        数据库索引好比是一本书前面的目录，能加快数据库的查询速度。索引分为聚簇索引和非聚簇索引两种，聚簇索引是按照数据存放的物理位置为顺序的，而非聚簇索引就不一样了；聚簇索引能提高多行检索的速度，而非聚簇索引对于单行的检索很快。

根据数据库的功能，可以在数据库设计器中创建三种索引：唯一索引、主键索引和聚集索引。

唯一索引

唯一索引是不允许其中任何两行具有相同索引值的索引。当现有数据中存在重复的键值时，大多数数据库不允许将新创建的唯一索引与表一起保存。数据库还可能防止添加将在表中创建重复键值的新数据。例如，如果在employee表中职员的姓(name)上创建了唯一索引，则任何两个员工都不能同姓。

主键索引

数据库表经常有一列或多列组合，其值唯一标识表中的每一行。该列称为表的主键。在数据库关系图中为表定义主键将自动创建主键索引，主键索引是唯一索引的特定类型。该索引要求主键中的每个值都唯一。当在查询中使用主键索引时，它还允许对数据的快速访问。

聚集索引

在聚集索引中，表中行的物理顺序与键值的逻辑（索引）顺序相同。一个表只能包含一个聚集索引。如果某索引不是聚集索引，则表中行的物理顺序与键值的逻辑顺序不匹配。与非聚集索引相比，聚集索引通常提供更快的数据访问速度。聚集索引和非聚集索引的区别，如字典默认按字母顺序排序，读者如知道某个字的读音可根据字母顺序快速定位。因此聚集索引和表的内容是在一起的。例如读者需查询某个生僻字，则需按字典前面的索引，具体按偏旁进行定位，找到该字对应的页数，再打开对应页数找到该字，这种通过两个地方而查询到某个字的方式就是非聚集索引。

索引的特点

优点

　　1.加快了数据的检索速度；
　　2.创建唯一性索引，保证数据库表中每一行数据的唯一性；
　　3.加速表和表之间的连接；
　　4.在使用分组和排序子句进行数据检索时，可以显著减少查询中分组和排序的时间；
　　5.建立索引之后，在信息查询过程中可以使用优化隐藏器，提高整个信息检索系统的性能。

缺点
　　1.索引需要占物理空间；
　　2.当对表中的数据进行增、删、改的时候，索引也要动态的维护，降低了数据的维护速度；
　　3.建立数据库过程中，对于索引的建立和维护也需要花费大量的时间。

创建索引的条件

可以基于数据库表中的单列或多列创建索引。多列索引可以区分其中一列可能有相同值的行。如果经常同时搜索两列或多列或按两列或多列排序时，索引也很有帮助。例如，如果经常在同一查询中为姓和名两列设置判据，那么在这两列上创建多列索引将很有意义。

检查查询的WHERE和JOIN子句。在任一子句中包括的每一列都是索引可以选择的对象。对新索引进行试验以检查它对运行查询性能的影响。考虑已在表上创建的索引数量。最好避免在单个表上有很多索引。检查已在表上创建的索引的定义，最好避免包含共享列的重叠索引。

检查某列中唯一数据值的数量，并将该数量与表中的行数进行比较。比较的结果就是该列的可选择性，这有助于确定该列是否适合建立索引，如果适合，确定索引的类型。

在创建索引的时候，应该考虑在哪些列上可以创建索引，在哪些列上不能创建索引。一般来说，应该在这些列上创建索引：

①在经常需要搜索的列上，可以加快搜索的速度；

②在作为主键的列上，强制该列的唯一性和组织表中数据的排列结构；

③在经常用在连接的列上，这些列主要是一些外键，可以加快连接的速度；

④在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的；

⑤在经常需要排序的列上创建索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询时间。

当然，对于有些列不应该创建索引。这些列具有下列特点：

①对于那些在查询中很少使用或者参考的列不应该创建索引。这是因为，既然这些列很少使用到，因此有索引或者无索引，并不能提高查询速度。相反，由于增加了索引，反而降低了系统的维护速度和增大了空间需求。

②对于那些只有很少数据值的列也不应该增加索引。这是因为，由于这些列的取值很少，例如人事表的性别列，在查询的结果中，结果集的数据行占了表中数据行的很大比例，即需要在表中搜索的数据行的比例很大。增加索引，并不能明显加快检索速度。

③对于那些定义为text, image和bit数据类型的列不应该增加索引。这是因为，这些列的数据量要么相当大，要么取值很少,不利于使用索引。

④当修改性能远远大于检索性能时，不应该创建索引。这是因为，修改性能和检索性能是互相矛盾的。当增加索引时，会提高检索性能，但是会降低修改性能。当减少索引时，会提高修改性能，降低检索性能。因此，当修改操作远远多于检索操作时，不应该创建索引。

总结一下就是如下情况下需要创建索引列：

• 经常需要搜索的列上
• 作为主键的列上
• 经常用在连接的列上，这些列主要是一些外键
• 经常需要根据范围进行搜索的列上
• 经常需要排序的列上
• 经常使用在where子句上面的列上

在如下情况下不需要创建索引列：

• 查询中很少用到的列
• 对于那些具有很少数据值的列，比如人事表的性别列等
• 对于那些定义为text,image的列
• 当对修改性能的要求远远大于搜索性能时

建立索引案例

最普通的情况，是为出现在where子句的字段建一个索引。

CREATE TABLE mytable(

idserial int primary key,

category_id int default 0 not null ,

user_id int default 0 not null ,

adddate int default 0 not null

);

SELECT * FROM mytable WHERE category_id=1;

如果在查询时常用类似上面这个语句，最直接的应对之道，是为category_id建立一个简单的索引：

CREATE INDEX mytable_category_id ON mytable (category_id);

那如果有不止一个选择条件呢？例如：

SELECT * FROM mytable WHERE category_id=1 AND user_id=2;

第一反应可能是，再给user_id建立一个索引。但这不是一个最佳的方法，可以建立多重的索引：

CREATE INDEX mytable_categoryid_userid ON mytable(category_id,user_id);

我们可以注意到命名的习惯，使用"表名_字段1名_字段2名"的方式。后面就会知道为什么这样做了。

现在已经为适当的字段建立了索引，不过，还是有点不放心吧，可能会问，数据库会真正用到这些索引吗？测试一下，对于大多数的数据库来说，这是很容易的，只要使用EXPLAIN命令：

EXPLAIN

SELECT * FROM mytable

WHERE category_id=1 AND user_id=2;

This is what Postgres 7.1 returns (exactlyasI expected)

NOTICE:QUERY PLAN:

Index Scan using mytable_categoryid_userid on

mytable(cost=0.00..2.02 rows=1 width=16)

EXPLAIN

以上是postgres的数据，可以看到该数据库在查询的时候使用了一个索引，而且它使用的是创建的第二个索引。我们可以通过索引命名很容易知道它使用适当的索引了。

紧接着，如果有个ORDERBY 子句呢？

SELECT * FROM mytable

WHERE category_id=1 AND user_id=2

ORDER BY adddate DESC;

很简单，就像为where子句中的字段建立一个索引一样，也为ORDER BY的子句中的字段建立一个索引：

CREATE INDEX mytable_categoryid_userid_adddate ON mytable (category_id,user_id,adddate);

看看EXPLAIN的输出，数据库多做了一个没有要求的排序，这下知道性能如何受损了吧。

EXPLAIN 

SELECT * FROM mytable

WHERE category_id=1 AND user_id=2

ORDER BY adddate DESC;

NOTICE:QUERY PLAN:

Sort(cost=2.03..2.03 rows=1 width=16)

Index Scanusing mytable_categoryid_userid_addda

on mytable(cost=0.00..2.02 rows=1 width=16)

EXPLAIN

为了跳过排序这一步，并不需要其它另外的索引，只要将查询语句稍微改一下。这里用的是postgres，将给该数据库一个额外的提示--在ORDER BY语句中，加入where语句中的字段。这只是一个技术上的处理，并不是必须的，因为实际上在另外两个字段上，并不会有任何的排序操作，不过如果加入，postgres将会知道哪些是它应该做的。

EXPLAIN SELECT * FROM mytable

WHERE category_id=1 AND user_id=2

ORDER BY category_id DESC,user_id DESC,adddate DESC;

NOTICE:QUERY PLAN:

Index Scan Backward using

mytable_categoryid_userid_addda on mytable(cost=0.00..2.02 rows=1 width=16)

EXPLAIN

不过如果数据库非常巨大，并且每日的页面请求达上百万算，想会获益良多的。不过，如果要做更为复杂的查询呢，例如将多张表结合起来查询，特别是where限制字句中的字段是来自不止一个表格时，应该怎样处理呢？

①通常都尽量避免这种做法，因为这样数据库要将各个表中的东西都结合起来，然后再排除那些不合适的行，搞不好开销会很大。

②如果不能避免，应该查看每张要结合起来的表，并且使用前面讲到的策略来建立索引，然后再用EXPLAIN命令验证一下是否使用了预料中的索引。如果是的话，就可以了，不是的话，可能要建立临时的表来将他们结合在一起，并且使用适当的索引。

要注意的是，建立太多的索引将会影响更新和插入的速度，因为它需要同样更新每个索引文件。对于一个经常需要更新和插入的表格，就没有必要为一个很少使用的where字句单独建立索引了，对于比较小的表，排序的开销不会很大，也没有必要建立另外的索引。

在刚开始的时候，如果表不大，没有必要作索引，一般来讲在需要的时候才作索引，也可用一些命令来优化表，例如MySQL可用"OPTIMIZETABLE"。

每个数据库都有自己的一些优化器，虽然可能还不太完善，但是它们都会在查询时对比过哪种方式较快，在某些情况下，建立索引的话也未必会快，例如索引放在一个不连续的存储空间时，这会增加读磁盘的负担，因此，哪个是最优，应该通过实际的使用环境来检验。