Mysql InnoDB索引原理

理解Mysql索引的原理和数据结构有助于我们更好的使用索引以及进行SQL优化，索引是在存储引擎层面实现的，所以不同的引擎实现的索引也有一定的区别，但是在生产环境中，我们最常用的就是InnoDB引擎和B树索引，OK，那本文要讨论的重点也同样是 InnoDB引擎下的B树索引 。

我们建立一个表来进行测试，表的DDL如下所示，我们要关注的是表t_book上的主键索引id和name author publish_date三列组成的索引test_index。

Mysql中的B树索引是使用B+树实现的，关于B+树的数据结构个人认为美团点评技术博客中Mysql索引原理及慢查询优化一文中介绍的非常详实，B+树的数据结构如下图所示。

图中浅蓝色块即磁盘块，根节点磁盘块中存储17和35两个数据，其中指针P1指向小于17的数据，指针P2指向大于17小于35的数据，指针P3指向大于35的数据。显然通过B+树索引查询数据与B+树的高度有关，如上图的B+树索引查找一个叶子节点的数据只需要三次磁盘IO，对于Mysql来说三层的B+树可以索引上百万的数据，这对于查询效率的提升是巨大的。

总结起来Mysql中B树索引有以下关键特点：

Mysql中的B树索引有两种数据存储形式，一种为聚簇索引，一种为二级索引。

InnoDB一般会使用表的主键来作为聚簇索引，如果一个表没有主键（不建议这么玩）InnoDB会选用一个唯一非空索引来代替，如果没有这样的索引，InnoDB会隐式建立一个聚簇索引。聚簇的含义即是数据行和相邻的键值紧凑的存储在一起，占据一块连续的磁盘空间，因此通过聚簇索引访问数据可以有效减少随机IO，通常使用聚簇索引查找比非聚簇索引查找速度更快。以我们建立的表t_book为例，聚簇索引即为自增主键id，其B树索引数据结构可以用下图来表示。

聚簇索引有以下关键特点：

InnoDB的B树索引中除了聚簇索引，就都是二级索引了，二级索引的含义是索引的叶子节点除了存储了索引值，还存储了主键id，在使用二级索引进行查询时，查找到二级索引B树上的叶子节点后还需要去聚簇索引上去查询真实数据，但是这里有一种特殊情况，即查询所需的所有字段在二级索引中都可以获取，此时就不需要再去回表查数据了，这种情况就是索引覆盖（EXPLAIN中EXTRA列中会出现USING INDEX，本文只关注索引结构，不详细讨论索引覆盖等技术的使用，如果深入理解索引的数据结构，索引覆盖等技术也没有那么神秘）。

在我们的测试表t_book中，test_index即为二级索引，由于我们把除了主键id所有的列都作为一个联合索引，所以在这个表上的查询都可以使用索引覆盖技术，但是具体生产环境中也不建议总是采用这种做法，索引列的增加也会增大插入更新数据时的索引更新成本，具体的优化要视具体情况决策。t_book上的二级索引test_index的索引结构由下图表示。

通过以上结构，我们可以推断出二级索引的以下关键特点：

索引覆盖：

最左前缀匹配：

二级索引可以说是我们在Mysql中最常用的索引，通过理解二级索引的索引结构可以更容易理解二级索引的特性和使用。

最后聊点轻松的索引结构，哈希索引就是通过哈希表实现的索引，即通过被索引的列计算出哈希值，并指向被索引的记录。

哈希索引有如下特性：

Mysql索引原理及慢查询优化

高性能Mysql 第三版

谈到索引，大家并不陌生。索引本身是一种数据结构，存在的目的主要是为了缩短数据检索的时间，最大程度减少磁盘 IO。

任何有数据的场景几乎都有索引，比如手机通讯录、文件系统（ext4\xfs\ntfs)、数据库系统（MySQL\Oracle）。数据库系统和文件系统一般都采用 B+ 树来存储索引信息，B+ 树兼顾写和读的性能，最极端时检索复杂度为 O(logN)，其中 N 指的是节点数量，logN 表示对磁盘 IO 扫描的总次数。

MySQL 支持的索引结构有四种：B+ 树，R 树，HASH，FULLTEXT。

B 树是一种多叉的 AVL 树。B-Tree 减少了 AVL 数的高度，增加了每个节点的 KEY 数量。

B 树的特性：（m 为阶数：结点的孩子个数最大值）

1. 树中每个节点最多含有 m 个孩子节点 (m>=2)；

2. 除根节点和叶子结点外，其他节点的孩子数量 >=ceil(m / 2)；

3. 若根节点不是叶子结点，最少有两个孩子

特殊情况：没有孩子的根结点，即根结点为叶子结点，整棵树只有一个根节点；

4. 每个非叶子结点中包含有 n 个关键字信息：(n，P0，K1，P1，K2，P2，......，Kn，Pn) 其中：

Ki (i=1...n) 为关键字，且关键字按顺序升序排序 K(i-1)<Ki

Pi 为指向儿子节点的指针，且指针 P(i-1) 指向的儿子节点里所有关键字均小于 Ki，但都大于 K(i-1)

关键字的个数 n 必须满足：[ceil(m / 2)-1]<= n <= m-1

如果一个结点有 n 个关键字，那么该结点有 n+1 个分支。这 n+1 个关键字按照递增顺序排列

所有叶子结点都出现在同一层，是所有遍历的终点位置

先从数据结构的角度来答。

题主应该知道b-树和b+树最重要的一个区别就是b+树只有叶节点存放数据，其余节点用来索引，而b-树是每个索引节点都会有data域。

这就决定了b+树更适合用来存储外部数据，也就是所谓的磁盘数据。

从mysql（inoodb）的角度来看，b+树是用来充当索引的，一般来说索引非常大，尤其是关系性数据库这种数据量大的索引能达到亿级别，所以为了减少内存的占用，索引也会被存储在磁盘上。

那么mysql如何衡量查询效率呢？磁盘io次数，b-树（b类树）的特定就是每层节点数目非常多，层数很少，目的就是为了就少磁盘io次数，当查询数据的时候，最好的情况就是很快找到目标索引，然后读取数据，使用b+树就能很好的完成这个目的，但是b-树的每个节点都有data域（指针），这无疑增大了节点大小，说白了增加了磁盘io次数（磁盘io一次读出的数据量大小是固定的，单个数据变大，每次读出的就少，io次数增多，一次io多耗时啊！），而b+树除了叶子节点其它节点并不存储数据，节点小，磁盘io次数就少。这是优点之一。

另一个优点是什么，b+树所有的data域在叶子节点，一般来说都会进行一个优化，就是将所有的叶子节点用指针串起来。这样遍历叶子节点就能获得全部数据，这样就能进行区间访问啦。

至于mongodb为什么使用b-树而不是b+树，可以从它的设计角度来考虑，它并不是传统的关系性数据库，而是以json格式作为存储的nosql，目的就是高性能，高可用，易扩展。首先它摆脱了关系模型，上面所述的优点2需求就没那么强烈了，其次mysql由于使用b+树，数据都在叶节点上，每次查询都需要访问到叶节点，而mongodb使用b-树，所有节点都有data域，只要找到指定索引就可以进行访问，无疑单次查询平均快于mysql（但侧面来看mysql至少平均查询耗时差不多）。

总体来说，mysql选用b+树和mongodb选用b-树还是以自己的需求来选择的。

---