为什么选择B+树，而不是B树，不是hash索引

数据库索引为什么使用B+树而不是hash索引

1. hash表只能匹配是否相等，不能实现范围查找，因为原先是有序的键值，经过哈希算法后，有可能变成不连续的了，就没办法再利用索引完成范围查询检索。

2. 当需要按照索引进行orderby的时候，hash值没办法支持排序，因为hash散列的特性，无法利用索引完成排序。

3. 组合索引可以支持部分索引查询，如（a，b，c）的组合索引，查询中只用到了a和b也可以查询，如果使用hash表，组合索引会将几个字段合并hash，没办法支持部分索引。

4. 当数据量很大的时候，hash冲突的概率也很大，特别是在有大量重复键值的情况下，哈希索引的效率是非常低的，因为存在哈希碰撞问题。

为什么选择B树（B+树）不选择红黑树

1. B树相对于红黑树而言更偏胖矮，红黑树这种结构，h很深，而I/0次数和h有关，h越深，相对应的I/0次数越多，执行效率就越低。
2. 数据库系统的设计设巧妙用了磁盘预读的原理，将一个节点的大小设置为等于一个页，这样每个节点只需要一次I/O就可以完全载入，而且由于逻辑上很近的节点在物理上可能很远（因为红黑树在物理存储上是一个数组的形式），假设当前节点在位置i,那么他的左子节点在位置2 * i，右子节点在位置2 * i+1，当i很大的话，那么根节点虽然在逻辑上与其子节点相差很近，但是实际在物理上相差很远，因此载入内存的时候无法利用局部性原理，效率比B-Tree要差很多。

为什么是B+树不选择B树

1. B+树的内部结点并没有指向关键字具体信息的指针。而是指向叶子节点中关键字的索引，所以节点所占用的空间就小。如果把所有同一内部结点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多。一次性读入内存中的需要查找的关键字也就越多，相对来说IO读写次数也就降低了。
2. 非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当，查找性能也就越稳定。
3. B+树只要遍历叶子节点就可以实现整棵树的遍历，而且在数据库中基于范围的查询是非常频繁的，而B树只能中序遍历所有节点，效率太低。
4. B+树方便扫库，然而B树必须用中序遍历的方法按序扫库，而B+树直接从叶子结点挨个扫一遍就完了，B+树支持range-query非常方便，而B树不支持，这是数据库选用B+树的最主要原因。

参考文章

B+树索引和哈希索引的区别
为什么mysql索引要使用B+树，而不是B树，红黑树
MySQL索引背后的数据结构及算法原理
为什么MySQL数据库要用B+树存储索引？
从B树、B+树、B*树谈到R 树
一步步分析为什么B+树适合作为索引的结构