索引的底层结构:
「这是我参与2022首次更文挑战的第22天,活动详情查看:2022首次更文挑战」。
- hash表和B+树
- B 树& B+树
首先说一下第一个底层结构(类比一下HashMap):
哈希表采用的是键值对,通过key能够快速的找到对应的值,所以哈希表可以快速检索数据(接近O1)
但是哈希表有一个问题就是哈希冲突:
不同的key通过哈希算法最后得到的映射值index是相同的,解决方法:
- 链地址法
- 开放寻址法
- 建立公共溢出区
在索引中的哈希冲突我们使用的是链地址法,但是索引并没有使用其作为数据结构。
从效率上看Hash比B+树更快
缺点:
- Hash冲突问题
- Hash 索引不支持顺序和范围查询(Hash 索引不支持顺序和范围查询是它最大的缺点
因为不是顺序存储的,每次查找数据都要进行哈希定位,当查找的数据很多时,会非常慢。
InnoDB本身不支持Hash索引,但是提供自适应Hash索引,什么情况会使用?
如果某个数据经常被访问,当满足一定条件的时候,就会将这个数据页的地址存放到Hash表中,在下次查询的时候,就可以直接找到这个页面的所在位置,这样让B+树也具备了Hash索引的有点。
B 树& B+树:
- B树所有的节点为key和 data,非叶子节点页存放数据,B+树只有叶子节点保存data
- B树叶子节点都是独立的,但是B+树叶子节点是单链表链接的
- B树的检索就是二分查找,B+树就是顺序查找,稳定
MySQL数据结构选择的合理性
首先是二叉搜索树,缺点是当所有的节点都一次递增的话,那么会退化成单链表结构,时间复杂度会成为O(n);
所以后面有了AVL树。
M叉树的高度远小于二叉树的高度(M > 2) 所以我们需要把树从瘦高变矮胖;
然后是B-Tree,
然后对其进行的改进有了B+ 树,其更适合文件索引系统。