【MySQL索引】

索引底层实现

数据库索引是储存在磁盘上的，当数据量大时，就不能把整个索引全部加载到内存了，只能逐一加载每一个磁盘块(对应索引树的节点)，索引树越低，越矮胖，磁盘IO次数就少

MySQL支持两种索引，一种的B-树索引，一种是哈希索引，大家知道，B-树和哈希表在数据查询时的效率是非常高的。

这里我们主要讨论一下MySQL InnoDB存储引擎，基于B-树（但实际上MySQL采用的是B+树结构）的索引结构。

B-树是一种m阶平衡树（m叉平衡树），叶子节点都在同一层，由于每一个节点存储的数据量比较大，索引整个B-树的层数是非常低的，基本上不超过三层。
由于磁盘的读取也是按block块操作的（内存是按page页面操作的），因此B-树的节点大小一般设置为和磁盘块大小一致，这样一个B-树节点，就可以通过一次磁盘I/O把一个磁盘块的数据全部存储下来，所以当使用B-树存储索引的时候，磁盘I/O的操作次数是最少的（MySQL的读写效率，主要集中在磁盘I/O上）。

碎片知识点：

上图data存储的是数据本身还是在磁盘上的地址。取决于存储引擎InnoDB的索引和数据存储在一起，所以data存储的就是数据本身。而MyISAM数据和索引分开存储，data存的就是数据对应的磁盘地址

数据和索引都是放在磁盘上的；MySQL Server读取数据时，请求操作系统把磁盘上的数据先加载到内存上（磁盘IO），然后才能访问相应的数据。

基于索引的 B 树结构，一次磁盘 IO 读取一个**数据页（Page）**，对应 B 树中的一个**节点**
B 树的每个节点对应一个磁盘页，高度通常为 3-4 层，因此仅需 3-4 次 IO 即可访问到数据。

select * from student where uid=5;    //uid索引

索引定位：
1. - MySQL 优化器识别到`WHERE uid=5`，发现`uid`字段有 B + 树索引，决定使用该索引加速查询。
2. **首次 IO**：读取 B + 树的根节点（通常常驻内存）
3. **内存比较**：在内存中通过二分查找比较`uid=5`，确定需访问的子节点指针（如指向`uid=3~7`的子节点）
4. **后续 IO**：根据指针读取对应的子节点（如第二层节点），重复内存比较，直到找到叶子节点。

为什么MySQL(MyISAM和InnoDB)索引底层选择B+树而不是B树?

1. B-树的每一个节点，存了关键字和对应的数据地址，而B+树的非叶子节点只存关键字，不存数据地址。因此B+树的每一个非叶子节点存储的关键字是远远多于B-树的，B+树的叶子节点存放关键字和数据，因此，从树的高度上来说，B+树的高度要小于B-树，使用的磁盘I/O次数少，因此查询会更快一些。

2. B-树由于每个节点都存储关键字和数据，因此离根节点进的数据，查询的就快，离根节点远的数据，查询的就慢；B+树所有的数据都存在叶子节点上，因此在B+树上搜索关键字，找到对应数据的时间是比较平均的，没有快慢之分。

3. 在B-树上如果做区间查找，遍历的节点是非常多的；B+树所有叶子节点被连接成了有序链表结构，因此做整表遍历和区间查找是非常容易的。

二级索引

InnoDB存储引擎下

场景一： `uid`是主键   搜索整个主键索引树，
场景二： `uid`是主键 `name`创建了普通索引（二级索引） 
二级索引树下，`key`是`name`,`data`是主键`uid`。

select name from student where name='linfeng';
select uid name from student where name='linfeng';

正常搜索二级索引树

但如果是此情况则需要回表

select * from student where name='linfeng';

1. 搜索`name`二级索引树，找到`linfeng`对应的主键`uid=5`
2. 再拿`uid=5`回表在主键索引树上搜索`uid=5`的那一行信息

MyISAM存储引擎下

 主键索引树和二级索引树没什么区别，唯一区别是主键的key不能重复

哈希索引

memory基于内存的存储引擎，使用的是哈希索引

• 存储方式：通过哈希函数将索引列的值映射为一个固定长度的哈希值，存入哈希表中，哈希表的每个条目指向数据行的物理地址（如磁盘块地址）。
• 查询逻辑：查询时对条件值计算哈希值，直接定位到哈希表中的条目，快速获取数据行。

Redis的哈希结构会直接存储**键值对的完整数据**，但这是由其 “内存存储 + 键值对模型” 决定的，与传统关系型数据库的哈希索引本质不同

搜索`O(1)` ，哈希表中的元素没有任何顺序可言，只能进行等值比较
 

select *from student where name='zhangsan';

范围搜索，前缀搜索，`order by`排序这些操作都是不合适的

select * from student where name like 'zhang%';

1. 没办法处理磁盘上的数据，加载到内存上构建高效的搜索数据结构，因为它没办法减少I/O的次数
2. 只适合做等值搜索，等值查询极快`O(1)`
3. 因为需要维护哈希表，所以内存消耗高
4. 适用场景：内存数据库(Redis)和高频的等值查询

InnoDB自适应哈希
InnoDB 存储引擎会监控对表上各索引页的查询，若发现建立哈希索引可提升速度，就会为某些热点页建立哈希索引。

比如，同样的二级索引不断被使用（回表），那它将会根据这个二级索引，在内存上根据二级索引（B+树）上的索引值，在内存上构建一个哈希索引

自适应的哈希索引本身的数据维护也是要消耗性能的，并不是说自适应哈希索引在任何情况下都会提升二级索引的查询性能。