索引

1、索引的定义

索引是一个单独的、物理的数据库结构，它是某个表中一列或若干列值的集合和相应的指向表中物理标识这些值的数据页的逻辑指针清单。

简单地说，索引是对数据库表中一列或多列的值进行排序的一种结构。

2、索引的优缺点

• 优点：

1.大大加快数据的检索速度，这也是创建索引的最主要的原因；
2.可以创建唯一性索引，保证数据库表中每一行数据的唯一性；
3.可以将表的外键制作为索引，加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义；
4.将随机I/O变为顺序I/O，帮助服务器避免排序和临时表，在使用分组和排序子句进行数据检索时，可以显著减少查询中分组和排序的时间；
5.通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。

• 缺点：

1.创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加；
2.索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间；
3.当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。

3、在哪建立索引

一般来说，应该在这些列上创建索引：

1.在经常需要搜索的列上，可以加快搜索的速度；
2.在作为主键的列上，强制该列的唯一性和组织表中数据的排列结构；
3.在经常用在连接的列上，这些列主要是一些外键，可以加快连接的速度；
4.在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的；
5.在经常需要排序的列上创建索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询时间；
6.在经常使用在WHERE子句中的列上面创建索引，加快条件的判断速度。

一般来说，不应该创建索引的的这些列具有下列特点：

1.对于那些在查询中很少使用或者参考的列不应该创建索引。这是因为，既然这些列很少使用到，因此有索引或者无索引，并不能提高查询速度。相反，由于增加了索引，反而降低了系统的维护速度和增大了空间需求。
2.对于那些只有很少数据值的列也不应该增加索引。这是因为，由于这些列的取值很少，例如人事表的性别列，在查询的结果中，结果集的数据行占了表中数据行的很大比例，即需要在表中搜索的数据行的比例很大。增加索引，并不能明显加快检索速度。
3.对于那些定义为text, image和bit数据类型的列不应该增加索引。这是因为，这些列的数据量要么相当大，要么取值很少，不利于使用索引。
4.当修改性能远远大于检索性能时，不应该创建索引。这是因为，修改性能和检索性能是互相矛盾的。当增加索引时，会提高检索性能，但是会降低修改性能。当减少索引时，会提高修改性能，降低检索性能。因此，当修改操作远远多于检索操作时，不应该创建索引。

4、索引结构

目前大部分数据库系统及文件系统都采用B-Tree或其变种B+Tree作为索引结构。Oracle使用B-Tree做索引，MySQL使用B+Tree做索引。

• B-Tree：

B-Tree是满足下列条件的数据结构：

1、每个非叶子节点由n-1个key和n个指针组成；

2、每个叶子节点最少包含一个key和两个指针，叶节点的指针均为null ；

3、所有叶节点具有相同的深度，等于树的高度h；

4、一个节点中的key从左到右按非递减顺序排列。

• B+Tree：

B+Tree和B-Tree的主要异同点在于：

1、叶子节点包含全部关键字的信息；

2、所有的内节点可以看成是索引部分，节点中仅含有其子树根结点中最大（或最小）关键字，最大化了内节点的分支因子。 B+Tree的内部结点并没有指向关键字具体信息的指针，因此其内部节点相对B树更小。如果把所有同一内部结点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多，一次性读入内存中的需要查找的关键字也就越多。相对来说I/O读写次数也就更少。

在B+Tree的每个叶子节点增加一个指向相邻叶子节点的指针，就形成了带有顺序访问指针的B+Tree。做这个优化的目的是为了提高区间访问的性能，例如上图中如果要查询key为从18到49的所有数据记录，当找到18后，只需顺着节点和指针顺序遍历就可以一次性访问到所有数据节点，极大提到了区间查询效率。

B+Tree的内部结点并没有指向关键字具体信息的指针，因此其内部节点相对B-Tree更小；在B+Tree的每个叶子节点增加一个指向相邻叶子节点的指针，形成带有顺序访问指针的B+Tree，极大提到了区间查询效率。所以B+Tree比B-Tree更适合实现数据库索引。

5、为什么使用B-Tree／B+Tree？

一般来说，索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储到磁盘上。这样的话，索引查找过程中就要产生磁盘I/O消耗，相对于内存存取，I/O存取的消耗要高几个数量级，所以索引的结构组织要尽量减少查找过程中磁盘I/O的存取次数。

为了达到这个目的，磁盘往往不是严格按需读取，而是每次都会预读，即使只需要一个字节，磁盘也会从这个位置开始，顺序向后读取一定长度的数据放入内存。这样做的理论依据是计算机科学中著名的局部性原理：当一个数据被用到时，其附近的数据也通常会马上被使用。程序运行期间所需要的数据通常比较集中。

由于磁盘顺序读取的效率很高（不需要寻道时间，只需很少的旋转时间），因此对于具有局部性的程序来说，预读可以提高I/O效率。

预读的长度一般为页（page）的整倍数。页是计算机管理存储器的逻辑块，硬件及操作系统往往将主存和磁盘存储区分割为连续的大小相等的块，每个存储块称为一页（在许多操作系统中，页得大小通常为4k），主存和磁盘以页为单位交换数据。

• B-/+Tree索引的性能分析

上文说过一般使用磁盘I/O次数评价索引结构的优劣。先从B-Tree分析，根据B-Tree的定义，可知检索一次最多需要访问h个节点。数据库系统的设计者巧妙利用了磁盘预读原理，将一个节点的大小设为等于一个页，这样每个节点只需要一次I/O就可以完全载入。为了达到这个目的，在实际实现B-Tree还需要使用如下技巧：

每次新建节点时，直接申请一个页的空间，这样就保证一个节点物理上也存储在一个页里，加之计算机存储分配都是按页对齐的，就实现了一个节点只需一次I/O。

B-Tree中一次检索最多需要h-1次I/O（根节点常驻内存），渐进复杂度为O(h)=O(log_dN)。一般在实际应用中，度d是非常大的数字，通常超过100，因此树的高度h非常小（通常不超过3）。            

（度：结点所拥有的子树的个数称为该结点的度(Degree)；树中各结点度的最大值称为该树的度；称度为m的树为m叉树。）

综上所述，用B-Tree作为索引结构有非常高的效率。由于B+Tree内节点不包含data域，内部节点相对于B-Tree更小，相对于B-Tree拥有更好的性能。

6、MySQL索引实现

在MySQL中，索引属于存储引擎级别的概念，不同存储引擎对索引的实现方式是不同的。

• MyISAM索引实现：

MyISAM引擎使用B+Tree作为索引结构，叶节点的data域存放的是数据记录的物理地址。

设数据表一共有三列，假设以Col1为主键，则下图是一个MyISAM表的主索引（Primary key）示意。可以看出MyISAM的索引文件仅仅保存数据记录的地址。

MyISAM中每张表被存放在三个文件：frm-表格定义、MYD(MYData)-数据文件、MYI(MYIndex)-索引文件。MyISAM的索引方式也叫做“非聚集索引”，之所以这么称呼是为了与InnoDB的聚集索引区分。

• InnoDB索引实现：

虽然InnoDB也使用B+Tree作为索引结构，但具体实现方式却与MyISAM截然不同。

InnoDB的数据和索引聚集在同一个文件中。从上文知道，MyISAM索引文件和数据文件是分离的，索引文件仅保存数据记录的地址。而在InnoDB中，表数据文件本身就是按B+Tree组织的一个索引结构，这棵树的叶节点data域保存了完整的数据记录，InnoDB的索引方式叫做“聚集索引”。这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引。

7、索引使用策略及优化

• 示例数据库

为了讨论索引策略，需要一个数据量不算小的数据库作为示例。本文选用MySQL官方文档中提供的示例数据库之一：employees。这个数据库关系复杂度适中，且数据量较大。下图是employees数据库的E-R关系图（引用自MySQL官方手册）：

• 最左前缀原理与相关优化

  高效使用索引的首要条件是知道什么样的查询会使用到索引，这个问题和B+Tree中的“最左前缀原理”有关，下面通过例子说明最左前缀原理。

  这里先说一下联合索引的概念。在上文中，我们都是假设索引只引用了单个的列，实际上，MySQL中的索引可以以一定顺序引用多个列，这种索引叫做联合索引，一般的，一个联合索引是一个有序元组<a1, a2, …, an>，其中各个元素均为数据表的一列。另外，单列索引可以看成联合索引元素数为1的特例。

  以employees.titles表为例，查看其上都有哪些索引：

  
  

  从结果中可以到titles表的主索引为<emp_no, title, from_date>。（1、Collation：用于指定数据集如何排序，以及字符串的比对规则。2、Cardinality：索引列的唯一值的个数，如果是联合索引就是唯一组合的个数。 Cardinality值越大，就意味着，使用索引能排除越多的数据，执行也更为高效。）

  情况一：全列匹配

  

  很明显，当按照索引中所有列进行精确匹配（这里精确匹配指“=”或“IN”匹配）时，索引可以被用到。

  这里有一点需要注意，理论上索引对顺序是敏感的，但是由于MySQL的查询优化器会自动调整where子句的条件顺序以使用适合的索引，例如将where中的条件顺序颠倒效果一样：
  
  

  情况二：最左前缀匹配

  
  
  当查询条件精确匹配索引的左边连续一个或几个列时，如<emp_no>或<emp_no, title>，所以可以被用到，但是只能用到一部分，即条件所组成的最左前缀。上面的查询从分析结果看用到了PRIMARY索引，但是key_len为4，说明只用到了索引的第一列前缀。

  情况三：查询条件用到了索引中列的精确匹配，但是中间某个条件未提供

  
  
  此时索引使用情况和情况二相同，因为title未提供，所以查询只用到了索引的第一列，而后面的from_date虽然也在索引中，但是由于title不存在而无法和左前缀连接，因此需要对结果进行扫描过滤from_date（这里由于emp_no唯一，所以不存在扫描）。
  
  由于联合索引按照索引顺序进行多级排序，查询时缺省title字段，第三个字段from_date是乱序的，此时查询只能对第一个索引查询出的结果进行扫描而无法使用索引。

情况四：查询条件没有指定索引第一列

由于不是最左前缀，索引这样的查询显然用不到索引。

情况五：匹配某列的前缀字符串

如果通配符%不出现在开头，则可以用到索引。

情况六：范围查询

范围列可以用到索引（必须是最左前缀），但是范围列后面的列无法用到索引。同时，索引最多用于一个范围列，因此如果查询条件中有两个范围列则无法全用到索引。

key_len=4，说明只用到了第一个索引，可以看到索引对第二个范围索引无能为力。

情况七：查询条件中含有函数或表达式

虽然这个查询和情况五中功能相同，但是由于使用了函数left，则无法为title列应用索引，而情况五中用LIKE则可以。

显然这个查询等价于查询emp_no为10001的函数，但是由于查询条件是一个表达式，MySQL无法为其使用索引。MySQL还没有智能到自动优化常量表达式的程度，因此在写查询语句时尽量避免表达式出现在查询中，而是先手工私下代数运算，转换为无表达式的查询语句。

• 索引选择性

• 前缀索引

  前缀索引是一种与索引选择性有关的索引优化策略，就是用列的前缀代替整个列作为索引key，当前缀长度合适时，可以做到既使得前缀索引的选择性接近全列索引，同时因为索引key变短而减少了索引文件的大小和维护开销。

  下面以employees.employees表为例介绍前缀索引的选择和使用。

  从employees数据库的E-R图可以看到employees表只有一个索引<emp_no>，那么如果按名字搜索一个人，就只能全表扫描。

  如果频繁按名字搜索员工，这样显然效率很低，因此可以考虑建索引。有两种选择，建<first_name>或<first_name, last_name>，看下两个索引的选择性：
  

  <first_name>显然选择性太低，<first_name, last_name>选择性很好，但是first_name和last_name加起来长度为30，有没有兼顾长度和选择性的办法？可以考虑用first_name和last_name的前几个字符建立索引，例如<first_name, left(last_name, 3)>，看看其选择性：

  

  选择性还不错，但离0.9313还是有点距离，那么把last_name前缀加到4：

  

  这时选择性已经很理想了，而这个索引的长度只有18，比<first_name, last_name>短了接近一半，能够有效地减少索引文件的大小。

  前缀索引兼顾索引大小和查询速度，但是由于只包含某列的前缀而不是整列，所以不能用于ORDER BY和GROUP BY操作，也不能用于覆盖索引（Covering index，即当索引本身包含查询所需全部数据时，不再访问数据文件本身）。

• InnoDB的主键选择与插入优化

  在使用InnoDB存储引擎时，如果没有特别的需要，最好使用一个与业务无关的自增字段作为主键。

  上文讨论过InnoDB的索引实现，InnoDB使用聚集索引，数据记录本身被存于主索引（一颗B+Tree）的叶子节点上。这就要求同一个叶子节点内（大小为一个内存页或磁盘页）的各条数据记录按主键顺序存放，因此每当有一条新的记录插入时，MySQL会根据其主键将其插入适当的节点和位置，如果页面达到装载因子（InnoDB默认为15/16），则开辟一个新的页（节点）。

  如果表使用自增主键，那么每次插入新的记录，记录就会顺序添加到当前索引节点的后续位置，当一页写满，就会自动开辟一个新的页。如下图所示：
  

  这样就会形成一个紧凑的索引结构，近似顺序填满。由于每次插入时也不需要移动已有数据，因此效率很高，也不会增加很多开销在维护索引上。

  如果使用非自增主键（如果身份证号或学号等），由于每次插入主键的值近似于随机，因此每次新纪录都要被插到现有索引页得中间某个位置：
  

  此时MySQL不得不为了将新记录插到合适位置而移动数据，甚至目标页面可能已经被回写到磁盘上而从缓存中清掉，此时又要从磁盘上读回来，这增加了很多开销，同时频繁的移动、分页操作造成了大量的碎片，得到了不够紧凑的索引结构，后续不得不通过OPTIMIZE TABLE来重建表并优化填充页面。

  因此，只要可以，请尽量在InnoDB上采用自增字段做主键。