索引的底层结构：
「这是我参与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+ 树，其更适合文件索引系统。