为什么MySQL使用B+树，而不是Hash、AVL、B树

为什么不是Hash呢？

 我们知道通过Hash直接计算数据的位置是十分迅速的。
 假如我们使用Hash对数据进行存储，当查询age = 1时，很快就能搞出来，但是。。如果我们进行范围查询如age>21，那就惨了，Hash搞不定了，只有全表扫描了。而在实际业务中，范围查找（如age>21）是很平凡的，所以呢，Hash不适用。

为什么不是平衡二叉树（AVL）?

 平衡二叉树尽可能的使二叉树饱满，但由于AVL是二叉的，如果存储数据太多，那么树会变得很高，节点很多，磁盘I/O次数会过多。
 为什么节点多，磁盘I/O就多呢？树从逻辑上，节点之间是很近的，但是在物理磁盘上，两者可能相距甚远，MySQL一次磁盘I/O会读取至少一页（页的大小跟所使用的引擎有关）的数据。由于节点之间相距甚远，所以MySQL一次磁盘I/O一般只会读取到一个节点，而二叉树的节点存储的东西很少，那么读到内存的内容，大部分都是无用的。并且由于节点过多，大大增加了磁盘I/O的次数。对此呢？B树就很好的解决了这个问题。

为什么不是B树？

 承上，B树又叫多路平衡搜索树，他是多叉的，那么一个节点存储的数据既可以比较多，这样加载的一页的有效数据就变多了，节点相比平衡二叉树会大大的减少，磁盘I/O也会大大的减少。
 但是相较于B+树来说，B树在叶子节点和非叶子节点都存储了数据和特征，B+树只在叶子节点存储数据，非叶子节点存储的是特征（即分支的判定条件），那么B+树的非叶子节点可以存储更多的特征，即节点树会更少，并且加载磁盘到内存是以页为单位的，那么如果采用B树，大概加载非叶子节点到内存进行判定下一步时，数据在多数情况下是用不到的，那么久白白浪费了这段加载空间。