搞懂MySQL中索引的数据结构究竟是什么

关联博文：
MySQL索引基础入门详解
MySQL索引中的数据结构详解
MySQL中的(非)聚簇索引与索引覆盖详解

学习完MySQL索引基础入门后，继续学习索引背后的数据结构和算法。

【1】数据结构及算法基础

① 几个概念

度和阶

树中一个结点的孩子个数称为该结点的度。树中结点的最大度数称为树的度。

度数：在树中 每个结点的子结点（子树）的个数就称为该结点的度（degree）。

阶数：B-tree 阶定义为一个结点的子结点数目的最大值（自带最大值属性）。

高度和深度

树的高度是树中结点最大层数。结点的层次从树根开始定义，根结点为第一层，子结点为第二层，依次类推。

结点的深度是从根结点开始自顶向下逐层累加的。

结点的高度是从叶结点开始自底向上逐层累加的。

关于Btree和B+tree的演示可以参考网址：Data Structure Visualizations

终端结点、内结点

度大于0的结点称为分支结点(又称非终端结点、内结点)，度为0（没有子女结点）结点称为叶子结点（又称为终端结点）。在分支结点中，每个结点的分支数就是该结点的度。

② 索引的本质

MySQL官方对索引的定义为：索引（Index）是帮助MySQL高效获取数据的数据结构。提取句子主干，就可以得到索引的本质：索引是数据结构。

从物理层面来讲索引是一种特殊的文件(InnoDB数据表上的索引是表空间的一个组成部分，索引记录着数据)，它们包含着对数据表里所有记录的引用指针(如MyISAM索引文件)。

我们知道，数据库查询是数据库的最主要功能之一。我们都希望查询数据的速度能尽可能的快，因此数据库系统的设计者会从查询算法的角度进行优化。最基本的查询算法当然是顺序查找（linear search），这种复杂度为O(n)的算法在数据量很大时显然是糟糕的。好在计算机科学的发展提供了很多更优秀的查找算法，例如二分查找（binary search）、二叉树查找（binary tree search）等。

每种查找算法都只能应用于特定的数据结构之上

例如二分查找要求被检索数据有序，而二叉树查找只能应用于二叉查找树上。但是数据本身的组织结构不可能完全满足各种数据结构（例如，理论上不可能同时将两列都按顺序进行组织）。所以在数据之外，数据库系统还维护着满足特定查找算法的数据结构.这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。

如下图所示，树的度为2

上图展示了MyIASM索引方式。

左边是数据表，一共有两列七条记录，最左边的是数据记录的物理地址（注意逻辑上相邻的记录在磁盘上也并不是一定物理相邻的）。为了加快Col2的查找，可以维护一个右边所示的二叉查找树，每个结点分别包含索引键值和一个指向对应数据记录物理地址的指针，这样就可以运用 二叉查找在O(logn) 的复杂度内获取到相应数据。

---

【2】B-Tree和B+Tree

B-Tree就是BTree。目前大部分数据库系统及文件系统都采用B-Tree或其变种B+Tree作为索引结构。MySQL中MyIsAM和InnoDB都是采用的B+树结构。不同的是前者是非聚集(聚簇)索引，后者主键是聚集(聚簇)索引。

所谓聚集索引是物理地址连续存放的索引，在取区间的时候，查找速度非常快，但同样的，插入的速度也会受到影响而降低。聚集索引的物理位置使用链表来进行存储。

① BTree

B树又称多路平衡查找树，B树中所有结点的孩子个数的最大值称为B树的阶，通常用m表示。一颗M阶B树或为空树，或为满足如下特性的 M (M >=2)叉树：

• 根节点的儿子数的范围是[2,M]
• 每个中间结点包括 k-1个关键字和 k 个孩子，孩子的数量=关键字数量+1 ，k的取值范围为[ceil(M/2),M]
• 叶子结点包含 k-1 个关键字（叶子节点没有孩子），k 的取值范围为[ceil(M/2),M]
• 假设中间节点节点的关键字为Key[1],Key[2],...,Key[k-1]，且关键字按照升序排序，即Key[i]<Key[i+1]。此时，k-1 个关键字相当于划分了 k 个范围，也就是对应着 k 个指针。即为：P[1],P[2],...,P[k]，其中P[1]指向关键字小于Key[1]的子树，P[i]指向关键字属于(Key[i-1],Key[i])的子树，P[k]指向关键字大于Key[k-1]的子树。
• 所有叶子节点位于同一层。

为了描述B-Tree，可以定义一条数据记录为一个二元组[key, data]，key为记录的键值，对于不同数据记录，key是互不相同的。data为数据记录除key外的数据。

如果一个结点有3条记录，那么会有对应的4个指针(key和指针互相间隔，结点两端是指针)，用以指向下一个结点。B-Tree是有序且平衡的，所有叶子结点在同一层，即不会出现某个分支层级多，某个分支层级少的情况。

如下是一棵树的度为3的BTree

由于B-Tree的特性，在B-Tree中按key检索数据的算法非常直观：

• 首先从根结点进行二分查找，如果找到则返回对应结点的data。

• 否则对相应区间的指针指向的结点递归进行查找，直到找到结点或找到null指针(前者查找成功，后者查找失败)。

检索一个key，其查找结点个数的渐进复杂度为O(logdN)(d是出度)。从这点可以看出，B-Tree是一个非常有效率的索引数据结构。

另外，由于插入删除新的数据记录会破坏B-Tree的性质，因此在插入删除时，需要对树进行一个分裂、合并、转移等操作以保持B-Tree性质。

这里也可以看到对于BTree，关键字集合分布在整棵树中，即叶子节点和非叶子节点都存放数据（row data）。搜索有可能在非叶子节点结束，其搜索性能等价于在关键字全集内做一次二分查找。

下图是MySQL基于BTree存储示意图：

② B+Tree

B+树也是一种多路搜索树，基于B树做出了改进，主流的DBMS都支持B+树的索引方式，比如MySQL。相比于BTree，B+Tree适合文件索引系统。

B+tree性质：

• 所有的叶子结点中包含了全部关键字的信息，及指向含这些关键字记录的指针(MyISAM是这样，InnoDB不是)，且叶子结点本身依关键字的大小自小而大顺序链接。
• 所有的非叶子结点可以看成是索引部分，结点中仅含其子树中的大（或小）关键字(这个说法不绝对)。
• B+树中，数据对象的插入和删除仅在叶结点上进行。
• B+树有2个头指针，一个是树的根结点，一个是小关键子的叶结点

与B-Tree相比，B+Tree有以下不同点：

• 有 k 个孩子的节点就有 k 个关键字。也就是孩子数量=关键字数量，而B树中，孩子数量=关键字数量+1。
• 非叶子节点的关键字也会同时存在于子节点中，并且是在子节点中所有关键字的最大（或最小）。
• 非叶子节点仅用于索引，不保存数据记录，跟记录有关的信息都放在叶子节点中。而B树中，非叶子节点既保存索引，也保存数据记录。
• 所有关键字都在叶子节点出现，叶子节点构成一个有序链表，而且叶子节点本身按照关键字的大小从小到大顺序链接。

下图是一个简单的B+Tree示意

由于并不是所有结点都具有相同的域(叶子节点有data，内节点没有data)，因此B+Tree中叶结点和内结点一般大小不同。这点与B-Tree不同，虽然B-Tree中不同结点存放的key和指针可能数量不一致，但是每个结点的域和上限是一致的，所以在实现中B-Tree往往对每个结点申请同等大小的空间。

一般数据库采用的是B+Tree，而且经过了一些优化，比如在叶子结点上增加了顺序访问指针，提高区间查询效率。

③ 带有顺序访问指针的B+Tree

一般在数据库系统或文件系统中使用的B+Tree结构都在经典B+Tree的基础上进行了优化，增加了顺序访问指针。

如图所示，在B+Tree的每个叶子结点增加一个指向相邻叶子结点的指针，就形成了带有顺序访问指针的B+Tree。

做这个优化的目的是为了提高区间访问的性能。例如图中如果要查询key为从18到49的所有数据记录，当找到18后，只需顺着结点和指针顺序遍历就可以一次性访问到所有数据结点，极大提到了区间查询效率。

④ 关于B+树的非叶子结点存储

有一种说法是，在MySQL的B+树数据结构中，真实的数据存在于叶子结点，非叶子结点只存储指引搜索方向的数据项(这些数据项并不真实存在于数据表)。

【3】为什么使用B-Tree（B+Tree）

前面说过，红黑树等数据结构也可以用来实现索引，但是文件系统及数据库系统普遍采用B-/+Tree作为索引结构，这一节将结合计算机组成原理相关知识讨论B-/+Tree作为索引的理论基础。

一般来说，索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上。这样的话，索引查找过程中就要产生磁盘I/O消耗，相对于内存存取，I/O存取的消耗要高几个数量级。所以评价 一个数据结构作为索引的优劣最重要的指标就是在查找过程中磁盘I/O操作次数的渐进复杂度。

换句话说，索引的结构组织要尽量减少查找过程中磁盘I/O的存取次数。下面先介绍内存和磁盘存取原理，然后再结合这些原理分析B-/+Tree作为索引的效率。

① 主存存取原理

目前计算机使用的主存基本都是随机读写存储器（RAM），现代RAM的结构和存取原理比较复杂，这里本文抛却具体差别，抽象出一个十分简单的存取模型来说明RAM的工作原理。

从抽象角度看，主存是一系列的存储单元组成的矩阵，每个存储单元存储固定大小的数据。每个存储单元有唯一的地址，现代主存的编址规则比较复杂，这里将其简化成一个二维地址：通过一个行地址和一个列地址可以唯一定位到一个存储单元。上图展示了一个4 x 4的主存模型。

主存的存取过程

当系统需要读取主存时，则将地址信号放到地址总线上传给主存。主存读到地址信号后，解析信号并定位到指定存储单元，然后将此存储单元数据放到数据总线上，供其它部件读取。

写主存的过程类似，系统将要写入单元地址和数据分别放在地址总线和数据总线上，主存读取两个总线的内容，做相应的写操作。

这里可以看出，主存存取的时间仅与存取次数呈线性关系。因为不存在机械操作，两次存取的数据的“距离”不会对时间有任何影响。例如，先取A0再取A1和先取A0再取D3的时间消耗是一样的。

---

② 磁盘存取原理

索引一般以文件形式存储在磁盘上，索引检索需要磁盘I/O操作。与主存不同，磁盘I/O存在机械运动耗费，因此磁盘I/O的时间消耗是巨大的。

下图是磁盘的整体结构示意图。

一个磁盘由大小相同且同轴的圆形盘片组成，磁盘可以转动（各个磁盘必须同步转动）。在磁盘的一侧有磁头支架，磁头支架固定了一组磁头，每个磁头负责存取一个磁盘的内容。磁头不能转动，但是可以沿磁盘半径方向运动（实际是斜切向运动），每个磁头同一时刻也必须是同轴的，即从正上方向下看，所有磁头任何时候都是重叠的（不过目前已经有多磁头独立技术，可不受此限制）。

下图是磁盘结构的示意图

盘片被划分成一系列同心环，圆心是盘片中心，每个同心环叫做一个磁道，所有半径相同的磁道组成一个柱面。磁道被沿半径线划分成一个个小的段，每个段叫做一个扇区，每个扇区是磁盘的最小存储单元。为了简单起见，我们下面假设磁盘只有一个盘片和一个磁头。

当需要从磁盘读取数据时，系统会将数据逻辑地址传给磁盘，磁盘的控制电路按照寻址逻辑将逻辑地址翻译成物理地址，即确定要读的数据在哪个磁道，哪个扇区。

为了读取这个扇区的数据，需要将磁头放到这个扇区上方，为了实现这一点，磁头需要移动对准相应磁道，这个过程叫做寻道，所耗费时间叫做寻道时间，然后磁盘旋转将目标扇区旋转到磁头下，这个过程耗费的时间叫做旋转时间。所以，适当的操作顺序和数据存放可以减少寻道时间和旋转时间。

---

③ 局部性原理与磁盘预读

由于存储介质的特性，磁盘本身存取就比主存慢很多，再加上机械运动耗费，磁盘的存取速度往往是主存的几百万分之一，因此为了提高效率，要尽量减少磁盘I/O。

为了达到这个目的，磁盘往往不是严格按需读取，而是每次都会预读，即使只需要一个字节，磁盘也会读取一页的数据(通常为4K或者8K)放入内存，内存与磁盘以页为单位交换数据。

这样做的理论依据是计算机科学中著名的局部性原理：

• 当一个数据被用到时，其附近的数据也通常会马上被使用。

• 程序运行期间所需要的数据通常比较集中。

由于磁盘顺序读取的效率很高（不需要寻道时间，只需很少的旋转时间），因此对于具有局部性的程序来说，预读可以提高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(logdN)。一般实际应用中，度d是非常大的数字，通常超过100，因此h非常小（通常不超过3）。

综上所述，用B-Tree作为索引结构效率是非常高的。

上文还说过，B+Tree更适合外存索引，原因和内结点的度d有关。从上面分析可以看到，d越大索引的性能越好，而度的上限取决于结点内key和data的大小：

dmax=floor(pagesize/(keysize+datasize+pointsize))

floor表示向下取整。由于B+Tree内结点去掉了data，因此可以存储更多的key，拥有更大的度(相比于B-Tree，更矮胖)，拥有更好的性能。

由于B+树的内部结点只存放key，不存放data。因此，一次读取，可以在内存页中获取更多的键，有利于更快地缩小查找范围。

B+树的叶结点由一条链相连。因此，当需要进行一次全数据遍历的时候，B+树只需要使用O(logN)时间找到最小的一个结点，然后通过链进行O(N)的顺序遍历即可。而B树则需要对树的每一层进行遍历，这会需要更多的内存置换次数，因此也就需要花费更多的时间。

⑤ B/B+更多对比

B树只适合随机检索，而B+树同时支持随机检索和顺序检索。

B+树空间利用率更高，可减少I/O次数，磁盘读写代价更低。

B+树的查询效率更加稳定。B树搜索有可能会在非叶子结点结束，越靠近根节点的记录查找时间越短，只要找到关键字即可确定记录的存在，其性能等价于在关键字全集内做一次二分查找。而在B+树中，只有访问到叶子节点才能找到对应的数据。

B+树的查询效率更高 。这是因为通常B+树比B树更矮胖（阶数更大，深度更小），查询所需要的磁盘IO也会更少。同样的磁盘页大小，B+树可以存储更多的节点关键字

在查询范围上，B+树的效率也比B树高 。 这是因为所有关键字都出现在B+树的叶子节点中，叶子节点之间会有指针，数据又是递增的，这使得我们范围查找可以通过指针连接查询。而在B树中则需要通过中序遍历才能完成查询范围的查找，效率要低很多。

增删文件（节点）时，B+效率更高。因为B+树的叶子节点包含所有关键字，并以有序的链表结构存储，这样可很好提高增删效率。

B+树在满足聚簇索引和覆盖索引的时候不需要回表查询数据

在B+树的索引中，叶子节点可能存储了当前的key值，也可能存储了当前的key值以及整行的数据，这就是聚簇索引和非聚簇索引。

在InnoDB中，只有主键索引是聚簇索引，如果没有主键，则挑选一个唯一键建立聚簇索引。如果没有唯一键，则隐式的生成一个键来建立聚簇索引。当查询使用聚簇索引时，在对应的叶子节点，可以获取到整行数据，因此不用再次进行回溯二次查询。

innodb中，在聚簇索引之上创建的索引称之为辅助索引，辅助索引访问数据总是需要二次查找，非聚簇索引都是辅助索引，像复合索引、前缀索引、唯一索引，辅助索引叶子节点存储的不再是行的物理位置，而是主键值。

【4】MySQL索引实现

在MySQL中，索引属于存储引擎级别的概念，不同存储引擎对索引的实现方式是不同的，本文主要讨论MyISAM和InnoDB两个存储引擎的索引实现方式。

① MyISAM索引实现

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

下图是MyISAM索引的原理图：

这里设表一共有三列，假设我们以Col1为主键，则上图是一个MyISAM表的主索引（Primary key）示意。

可以看出MyISAM的索引文件仅仅保存数据记录的地址。

在MyISAM中，主索引和辅助索引（Secondary key）在结构上没有任何区别，只是主索引要求key是唯一的，而辅助索引的key可以重复。如果我们在Col2上建立一个辅助索引，则此索引的结构如下图所示（MyISAM中主索引和辅助索引结构没有任何区别）：

同样也是一颗B+Tree，data域保存数据记录的地址。因此，MyISAM中索引检索的算法为首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，则取出其data域的值，然后以data域的值为地址，读取相应数据记录。

MyISAM的索引方式也叫做“非聚集”的，之所以这么称呼是为了与InnoDB的聚集索引区分。

---

② InnoDB索引实现

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

第一个重大区别是InnoDB的数据文件本身就是主索引文件。

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

上图是InnoDB主索引（同时也是数据文件）的示意图，可以看到叶结点包含了完整的数据记录。

这种索引叫做聚集索引。因为InnoDB的数据文件本身要按主键聚集，所以InnoDB要求表必须有主键（MyISAM可以没有）。

如果没有显式指定，则MySQL系统会自动选择一个可以唯一标识数据记录的列作为主键。如果不存在这种列，则MySQL自动为InnoDB表生成一个隐含字段作为主键，这个字段长度为6个字节，类型为长整形。

第二个与MyISAM索引的不同是InnoDB的辅助索引data域存储相应记录主键的值而不是地址。

换句话说，InnoDB的所有辅助索引都引用主键作为data域。例如，下图为定义在Col3上的一个辅助索引：

这里以英文字符的ASCII码作为比较准则。聚集索引这种实现方式使得按主键的搜索十分高效，但是辅助索引搜索需要检索两遍索引：首先检索辅助索引获得主键，然后用主键到主索引中检索获得记录。

③ 为什么InnoDB主键不要使用UUID

了解不同存储引擎的索引实现方式对于正确使用和优化索引都非常有帮助。

例如知道了InnoDB的索引实现后，就很容易明白为什么不建议使用过长的字段作为主键，因为所有辅助索引都引用主索引，过长的主索引会令辅助索引文件变得过大。

再例如，用非单调的字段作为主键在InnoDB中不是个好主意。因为InnoDB数据文件本身是一颗B+Tree，非单调的主键会造成在插入新记录时数据文件为了维持B+Tree的特性而频繁的分裂调整，十分低效，而使用自增字段作为主键则是一个很好的选择。

使用自增ID作为主键

因为主键的值是顺序的，索引InnoDB把每条记录都存储在上一条记录的后面。当达到页的最大填充因子时（InnoDB默认的最大填充因子是页大小的15/16，留出部分空间用于以后修改），下一条记录就会写入新的页中。一旦数据按照这种顺序的方式加载，主键页就会近似于被顺序的记录填满，这也是所期望的结果（然而，二级索引可能是不一样的）。

如果使用了UUID

如果使用了UUID，新行的主键值不一定比之前插入的大，所以InnoDB无非简单地总是把新行插入到索引的最后，而是需要为新的行寻找合适的位置—通常是已有数据的中间位置–并且分配空间。这会增加很多的额外工作，并导致数据分别不够优化。

下面是总结的一些缺点：

• 写入的目标页可能已经刷到磁盘上并从缓存中移除，或者是还没有被加载到缓存中，InnoDB在插入之前不得不先找到并从磁盘读取目标页到内存中。这将导致大量的随机IO。
• 因为写入是乱序的，InnoDB不得不频繁地做页分裂操作，以便为新的行分配空间。页分裂会导致移动大量数据，一次插入最少需要修改三个页码而不是一个页。
• 由于频繁的页分裂，页会变得稀疏并被不规则地填充，所以最终数据会有碎片。

故而使用InnoDB时应该尽可能地按照主键顺序插入数据，并且尽可能地使用单调增加的聚簇键的值来插入新行。

【5】Hash索引

① 基本介绍

Hash本身是一个函数，又被称为散列函数，它可以帮助我们大幅提升检索数据的效率。Hash算法是通过某种确定性的算法（比如MD5、SHA1、SHA2、SHA3）将输入转变为输出。相同的输入永远可以得到相同的输出。假设输入内容有微小偏差，在输出中通常会有不同的结果。

以常见校验文件是否相同为例。如果你想要验证两个文件是否相同，那么你不需要把两份文件直接拿出来比对，只需要让对方把Hash函数计算得到的结果告诉你即可。然后再本地同样对文件进行Hash函数的运算，最后通过比较这两个Hash函数的结果是否相同，就可以知道这两个文件是否相同。

加速查找速度的数据结构，常见的有两类：

• 树，例如平衡二叉搜索树，查询、插入、修改、删除的平均时间复杂度都是O(logN);
• 哈希，例如HashMap，查询、插入、修改、删除的平均时间复杂度都是O(1)。

采用Hash进行检索效率非常高，基本上一次检索就可以找到数据。而B+树需要自顶向下依次查找，多次访问节点才能找到数据，中间需要多次IO操作，从效率来说Hash比B+树更快。

在哈希的方式下，一个元素k处于h(k)中，即利用哈希函数h，根据关键字k计算出槽的位置。函数h将关键字域映射到哈希表T[0...m-1]的槽位上。至于哈希函数可能将两个不同的关键字映射到相同的位置上造成碰撞，解决方案可以联想HashMap(拉链法&红黑树)。

② 为什么索引结构要设计为树型？

① Hash索引仅能满足 = <> 和IN 查询。如果进行范围查询，哈希型的索引，时间复杂度会退化为O(n)。而树型的“有序”特性，依然能够保持O(logN)的高效率。

② Hash索引数据存储是没有顺序的，在order by 的情况下，使用Hash索引还需要对数据重新排序。同理，Hash索引不支持范围查询。

③ Hash索引不支持键的部分匹配。对于联合索引的情况，Hash值是将联合索引键合并后一起来计算的，无法对单独的一个键或者几个索引键进行查询。

④ Hash索引不支持模糊查询以及多列索引的最左前缀匹配。原理也是因为hash函数的不可预测。AAAA和AAAAB的索引没有相关性。

由于索引仅包含hash code和记录指针，所以，MySQL不能通过使用索引避免读取记录。如果只是访问内存中的记录是非常迅速的，不会对性造成太大的影响。

Hash索引底层就是hash表，进行查找时，调用一次hash函数就可以获取到相应的键值，之后进行回表查询获得实际数据。

B+树底层实现是多路平衡查找树。对于每一次的查询都是从根结点出发，查找到叶子结点方可以获得所查键值，然后根据查询判断是否需要回表查询数据。

Hash索引任何时候都避免不了回表查询数据，而B+树在符合某些条件(聚簇索引，覆盖索引等)的时候可以只通过索引完成查询。

Hash索引虽然在等值查询上较快，但是不稳定。性能不可预测。当某个键值存在大量重复的时候，发生hash碰撞，此时效率可能极差。而B+树的查询效率比较稳定，对于所有的查询都是从根结点到叶子结点，且树的高度较低。

因此，在大多数情况下，直接选择B+树索引可以获得稳定且较好的查询速度。而不需要使用Hash索引。

③ Hash索引的适用性

Hash索引存在着很多限制，相比之下在数据库中B+树索引的使用面会更广。不过也有一些场景采用Hash索引效率更高，比如在键值型（key-value）数据库中，Redis存储的核心就是Hash表。

MySQL中的Memory存储引擎支持Hash存储。如果我们需要用到查询的临时表时，就可以选择Memory存储引擎，把某个字段设置为Hash索引。比如字符串类型的字段，进行Hash计算之后长度可以缩短到几个字节。当字段的重复度低，而且经常需要进行等值查询的时候，采用Hash索引是个不错的选择。

另外，InnoDB本身不支持Hash索引，但是提供自适应Hash索引（Adaptive Hash Index）。什么情况下才会使用自适应Hash索引呢？如果某个数据经常被访问，当满足一定条件的时候，就会将这个数据页的地址存放到Hash表中。这样下次查询的时候，就可以直接找到这个页面的所在位置。这样让B+树也具备了Hash索引的优点。

采用自适应Hash索引目的是方便根据SQL的查询条件加速定位到叶子节点，特别是当B+树比较深的时候，通过自适应Hash索引可以明显提高数据的检索效率。

可以通过 innodb_adaptive_hash_index 变量查看，默认是开启自定义Hash：show variables like '%innodb_adaptive_hash%'

【6】几个思考

① 为了减少IO，索引树会一次性加载吗？

答案：很显然是不会的。数据库索引是存储在磁盘上的，如果数据量很大，必然导致索引的大小也很大，超过几个G。当我们利用索引查询的时候，是不可能将全部几个G的索引都加载进内存的，我们能做的只能是：逐一加载每一个磁盘页，因为磁盘页对应着索引树的节点。

② B+数的存储能力如何？为何说一般查找行记录，最多只需1-3次磁盘IO

InnoDB存储引擎中页的大小为16KB，一般表的主键类型为INT(占用4个字节)或bigint(占用8个字节)，指针类型也一般为4或8个字节，也就是说一个页（B+Tree中的一个节点）中大概存储16KB/(8B+8B)=1K个键值（估值方便计算，K取1000）。也就是说一个深度为3的B+tree索引可以维护100010001000=10亿条记录（这里假设一个数据页也存储1000条行记录数据）。

实际情况中每个节点可能不能填充满，因此在数据库中B+Tree的高度一般都在2~4层。MySQL的InnoDB存储引擎在设计时是将根节点常驻内存的，也就是说查找某一键值的行记录时最多只需要1-3次磁盘IO。

③ 为什么说B+树比B-树更适合实际应用中操作系统的文件索引和数据库索引

1.B+树的磁盘读写代价更低

B+数的内部节点并没有指向关键字具体信息的指针。因此其内部结点相对B树更小。如果把所有同一内部结点的关键字放在同一盘块中，那么盘块所能容纳的关键字数量也越多。一次性读入内存中的需要查找的关键字也就越多，相对来说IO读写次数也就降低了。

2.B+树的查询效率更加稳定

由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根节点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。

参考博文：
MySQL索引背后的数据结构及算法原理