MySQL高级第三篇：Hash索引，AVL树，B树和B+树对比

• 从MySQL的角度来讲，如果我们能让索引的数据结构尽量减少硬盘的I/O操作，所消耗的时间也就越小。
• 但当数据越大的时候，索引所占空间也就越大，我们难以一次性加载整个索引到内存，所以选择一个合理的数据结构就比较重要了。

一、Hash结构

Hash本身是一个函数，可以帮助我们大大提高检索效率，因为它相同的输入永远可以得到相同的输出

1. 为什么索引结构选择树形而不是Hash结构？

• 1.Hash只能满足等于，不等于的查询，而在范围查询时，树形结构比Hash结构的效率高
• 2.Hash索引数据的存储是没有顺序的，在order by情况下，使用Hash索引还需对数据重新排序。
• 3.对于联合索引，Hash值是将联合索引键合并一起计算的，不能分开查询
• 4.如果索引列重复值很多，Hash结构很发生Hash冲突，效率降低。

Hash索引还有Memory支持

2. Hash索引适应场景

• 1.Redis 存储的核心就是Hash表
• 2.在Memory存储引擎时，当字段重复度低且经常等值查询时，Hash索引非常不错
• 3.InnoDB不支持Hash索引，但提供了自适应Hash
  • 如果某个数据经常被访问,当满足一定条件的时候,就会将这个数据页的地址存放到Hash表中。这样下次查询的时候，就可以直接找到这个页面的所在位置。这样让B+树也具备了Hash索引的优点。

二、平衡二叉搜索树(AVL)

二叉搜索树在后一个值总比前一个值大时，就会退化成线性结构

• 它是一棵空树或它的左右两个子树的高度差的绝对值不超过1，并且左右两个子树都是一棵平衡二叉树。

• 平衡了之后确实减少了I/O次数
• 但明显可以发现，这棵树的深度越大，磁盘I/O次数就越多，那为什么不让这棵树更胖一点呢?

三、B树

• B树，也叫多路平衡查找树，它的高度远小于平衡二叉树的高度。
• 特点：
  • 1.B树在插入和删除节点的时候如果导致树不平衡，就通过自动调整节点的位置来保持树的自平衡。
  • 2.关键字集合分布在整棵树中，即叶子节点和非叶子节点都存放数据。搜索有可能在非叶子节点结束。
  • 3.其搜索性能等价于在关键字全集内做一次二分查找。
    

四、B+树

• B+树也是一种多路搜索树，它基于B树做了改进。

1.B+树相对于B树的改进

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

2. 优点

• B+树查询效率更稳定，因为B+树每次只有访问到叶子节点才能找到对应的数据，而B树比较随机，有时候访问到了非叶子节点就可以找到关键字。
• B+树的查询效率更高，因为通常B+树比B树更矮胖。
• 在查询范围上,B+树的效率也比B树高。因为所有关键字都出现在B+树的叶子节点中，叶子节点之间会有指针且递增，我们范围查找可以通过指针连接查找。

五、为什么查找行记录最多只需要1-3次磁盘I/O

• 存储引擎页大小为16K，假设一个数据页可以存储100条数据，一个目录页可以存储1000条数据
• 那么三层 1000 * 1000 * 100 = 1亿条记录，基本可以满足需求
• 在实际操作中，数据也有可能超过1亿，或者每个页节点可能没有填满，所以 最高也就四层了
• 但是呢，我们的根节点是创建表就直接创建，在内存中常驻不变的，所以，最多就是三次磁盘I/O