Mysql InnoDB 为啥选择B+树索引

前言

Mysql数据库中的常见索引有多种方式，例如Hash索引，B-树索引，B+树索引，可是为啥mysql中默认是采用B+树索引索引呢？下面对这三种索引学习总结一下。B+树到底有啥优点？
B-树

B-树,这里的 B 表示 balance( 平衡的意思),B-树是一种多路自平衡的搜索树(不是二叉树)。它相似普通的平衡二叉树，不一样的一点是B-树容许每一个节点有更多的子节点。下图是 B-树的简化图。

B-树有以下特色:

    全部键值分布在整颗树中；

    任何一个关键字出现且只出如今一个结点中；

    搜索有可能在非叶子结点结束；

    在关键字全集内作一次查找,性能逼近二分查找；

 B+ 树

B+树是为磁盘及其余存储辅助设备而设计一种平衡查找树（不是二叉树）。B+树中，全部记录的节点按大小顺序存放在同一层的叶节点中，各叶节点用指针进行链接。B+树从根节点到叶子节点的搜索效率基本至关，不会出现大幅波动。

简化 B+树 以下图

B+树有以下特色

    B+树每一个节点能够包含更多的节点，这样作有两个缘由,一个是下降树的高度。另一个是将数据范围变为多个区间，区间越多，数据检索越快。占用空间很是小，所以每一层的节点能索引到的数据范围更加的广。换句话说，每次IO操做能够搜索更多的数据。
    每一个节点再也不只是存储一个key了，能够存储多个key。

    非叶子节点存储key，叶子节点存储key和数据。

    叶子节点两两指针相互连接，顺序查询性能更高。叶子节点两两相连，符合磁盘的预读特性。好比叶子节点存储50和55，它有个指针指向了60和62这个叶子节点，那么当咱们从磁盘读取50和55对应的数据的时候，因为磁盘的预读特性，会顺便把60和62对应的数据读取出来。这个时候属于顺序读取，而不是磁盘寻道了，加快了速度。

哈希索引

哈希索引就是采用必定的哈希算法，把键值换算成新的哈希值，检索时不须要相似B+树那样从根节点到叶子节点逐级查找，只需一次哈希算法便可马上定位到相应的位置，速度很是快。

 

从上面的图来看，B+树索引和哈希索引的明显区别是：

    若是是等值查询，那么哈希索引明显有绝对优点，由于只须要通过一次算法便可找到相应的键值；固然了，这个前提是，键值都是惟一的。若是键值不是惟一的，就须要先找到该键所在位置，而后再根据链表日后扫描，直到找到相应的数据；

    若是是范围查询检索，这时候哈希索引就毫无用武之地了，由于原先是有序的键值，通过哈希算法后，有可能变成不连续的了，就没办法再利用索引完成范围查询检索；

    哈希索引也没办法利用索引完成排序，以及like ‘xxx%’ 这样的部分模糊查询（这种部分模糊查询，其实本质上也是范围查询）；

    哈希索引也不支持多列联合索引的最左匹配规则；

    B+树索引的关键字检索效率比较平均，不像B树那样波动幅度大，在有大量重复键值状况下，哈希索引的效率也是极低的，由于存在所谓的哈希碰撞问题。

总结

上面大体介绍了B-树，B+树，哈希索引。那么B+树的优点大体总结以下

    不一样于B-树只适合随机检索，B+树同时支持随机检索和顺序检索；
    B+树的磁盘读写代价更低。B+树内部结点比B-树小，盘块能容纳的结点中关键字数量更多，一次性读入内存中能够查找的关键字也就越多，相对的，IO读写次数也就下降了。而IO读写次数是影响索引检索效率的最大因素。
    B+树的查询效率更加稳定。B-树搜索有可能会在非叶子结点结束，越靠近根节点的记录查找时间越短，只要找到关键字便可肯定记录的存在，其性能等价于在关键字全集内作一次二分查找。而在B+树中，顺序检索比较明显，随机检索时，任何关键字的查找都必须走一条从根节点到叶节点的路，全部关键字的查找路径长度相同，致使每个关键字的查询效率至关。
    B-树在提升了磁盘IO性能的同时并无解决元素遍历的效率低下的问题。B+树的叶子节点使用指针顺序链接在一块儿，只要遍历叶子节点就能够实现整棵树的遍历。并且在数据库中基于范围的查询是很是频繁的，而B-树不支持这样的操做（或者说效率过低）。

参考文献

1.https://blog.csdn.net/m0_37947204/article/details/81046943

2.https://segmentfault.com/a/1190000004690721

3.https://blog.csdn.net/mine_song/article/details/63251546

4.http://www.cnblogs.com/zengkefu/p/5647279.html