数据库索引：索引并不是万能药

几乎所有的业务项目都会涉及数据存储，虽然当前各种NoSQL和文件系统大行其道，但MySQL等关系型数据库因为满足ACID、可靠性高、对开发友好等特点，仍然最常被用于存储重要数据。在关系型数据库中，索引是优化查询性能的重要手段。

为此，我经常看到一些同学一遇到查询性能问题，就盲目要求运维或DBA给数据表相关字段创建大量索引。显然，这种想法是错误的。今天，我们就以MySQL为例来深入理解下索引的原理，以及相关误区。

InnoDB是如何存储数据的？

MySQL把数据存储和查询操作抽象成了存储引擎，不同的存储引擎，对数据的存储和读取方式各不相同。MySQL支持多种存储引擎，并且可以以表为粒度设置存储引擎。因为支持事务，我们最常使用的是InnoDB。为方便理解下面的内容，我先和你简单说说InnoDB是如何存储数据的。

虽然数据保存在磁盘中，但其处理是在内存中进行的。为了减少磁盘随机读取次数，InnoDB采用页而不是行的粒度来保存数据，即数据被分成若干页，以页为单位保存在磁盘中。InnoDB的页大小，一般是16KB。

各个数据页组成一个双向链表，每个数据页中的记录按照主键顺序组成单向链表；每一个数据页中有一个页目录，方便按照主键查询记录。数据页的结构如下：

 

页目录通过槽把记录分成不同的小组，每个小组有若干条记录。如图所示，记录中最前面的小方块中的数字，代表的是当前分组的记录条数，最小和最大的槽指向2个特殊的伪记录。有了槽之后，我们按照主键搜索页中记录时，就可以采用二分法快速搜索，无需从最小记录开始遍历整个页中的记录链表。

举一个例子，如果要搜索主键（PK）=15的记录：

• 先二分得出槽中间位是(0+6)/2=3，看到其指向的记录是12＜15，所以需要从#3槽后继续搜索记录；
• 再使用二分搜索出#3槽和#6槽的中间位是(3+6)/2=4.5取整4，#4槽对应的记录是16＞15，所以记录一定在#4槽中；
• 再从#3槽指向的12号记录开始向下搜索3次，定位到15号记录。

理解了InnoDB存储数据的原理后，我们就可以继续学习MySQL索引相关的原理和坑了。

聚簇索引和二级索引

说到索引，页目录就是最简单的索引，是通过对记录进行一级分组来降低搜索的时间复杂度。但，这样能够降低的时间复杂度数量级，非常有限。当有无数个数据页来存储表数据的时候，我们就需要考虑如何建立合适的索引，才能方便定位记录所在的页。

为了解决这个问题，InnoDB引入了B+树。如下图所示，B+树是一棵倒过来的树：

 

B+树的特点包括：

• 最底层的节点叫作叶子节点，用来存放数据；
• 其他上层节点叫作非叶子节点，仅用来存放目录项，作为索引；
• 非叶子节点分为不同层次，通过分层来降低每一层的搜索量；
• 所有节点按照索引键大小排序，构成一个双向链表，加速范围查找。

因此，InnoDB使用B+树，既可以保存实际数据，也可以加速数据搜索，这就是聚簇索引。如果把上图叶子节点下面方块中的省略号看作实际数据的话，那么它就是聚簇索引的示意图。由于数据在物理上只会保存一份，所以包含实际数据的聚簇索引只能有一个。

InnoDB会自动使用主键（唯一定义一条记录的单个或多个字段）作为聚簇索引的索引键（如果没有主键，就选择第一个不包含NULL值的唯一列）。上图方框中的数字代表了索引键的值，对聚簇索引而言一般就是主键。

我们再看看B+树如何实现快速查找主键。比如，我们要搜索PK=4的数据，通过根节点中的索引可以知道数据在第一个记录指向的2号页中，通过2号页的索引又可以知道数据在5号页，5号页就是实际的数据页，然后再通过二分法查找页目录马上可以找到记录的指针。

为了实现非主键字段的快速搜索，就引出了二级索引，也叫作非聚簇索引、辅助索引。二级索引，也是利用的B+树的数据结构，如下图所示：

 

这次二级索引的叶子节点中保存的不是实际数据，而是主键，获得主键值后去聚簇索引中获得数据行。这个过程就叫作回表。

举个例子，有个索引是针对用户名字段创建的，索引记录上面方块中的字母是用户名，按照顺序形成链表。如果我们要搜索用户名为b的数据，经过两次定位可以得出在#5数据页中，查出所有的主键为7和6，再拿着这两个主键继续使用聚簇索引进行两次回表得到完整数据。

考虑额外创建二级索引的代价

创建二级索引的代价，主要表现在维护代价、空