【mysql】关于mysql的数据结构特点索引特点

向右看齐 2024-03-02 10:49 33阅读 0赞

#### 文章目录 ####

*  二叉树
 *   *  红黑树
 *  b tree
 *  hash结构
 *  b+ tree
 *   *  索引存放特点
     *   *  myisam
         *  InnoDB
 *  最左原则
 *  主键相关知识点
 *  缓存池
 *   *  淘汰机制

> 前言：翻自己博客 发现缺少mysql数据结构和索引相关内容  
> 两年前整理的mysql知识点 一直存在于博主的笔记本里面  
> （是的 纸质的那种笔记本 不是程序员吃饭用的笔记本）

## 二叉树 ##

> 二叉树特点 小数在左 大数在右

如下图 (鼠标不太方便画图 将就着看吧 能看懂就行):

![在这里插入图片描述][fd8b42ebbe8f40d4a4dbaf6ff3255f6e.png]

> 当数据不规律的时候 二叉树就会变化成链表 ，所以MySQL放弃二叉树

如下图 : (具体的数字单纯是博主方便鼠标好画 随意举例的)  
![在这里插入图片描述][6a83ef17c41549afbc1790f9f11ad1c7.png]

### 红黑树 ###

> 红黑树也叫平衡二叉树，会自动旋转

![在这里插入图片描述][06b2df137b9749a3a953b3831926fb61.png]  
那既然会自动旋转了，解决了变成链表的问题 会不会有其它问题呢？答案是肯定的，当数据量大的时候，树的高度就会增加，如下图:  
![在这里插入图片描述][7043335e6f644365a5b6f0e5a6b1c5b9.png]

## b tree ##

既然红黑树会有高度的问题，那么 b tree就在优化这个问题：

> btree在红黑树的基础上，有了更多的根节点，降低了树的高度，从而降低了磁盘访问次数。  
> 当然 根节点是完全可能因为数据的变化而变化的

这也是博主自认为最通俗的理解了，我们可以借助工具网站来观察:  
![在这里插入图片描述][47bcc104b2744333bb969cf6a2c75a6a.jpeg]

## hash结构 ##

在介绍b+tree之前 我们也简单提一下hash结构，当前mysql版本两大结构就是hash和b+tree了。

hash结构拥有快速的插入和查找速度，但是由于hash的无序性，它并不适合范围查找。

> hash结构的主要两大缺点：
> 
> 1.  不支持范围查找
> 2.  极小概率hash冲突

## b+ tree ##

> b+tree在btree的基础上，子节点之间都有指针连接，且子节点是个有序链表，更适合作为数据库索引的结构，更利于查询，自然也更好的支持范围查找。

![在这里插入图片描述][f46b41dd110944c7aa7291bb7d292a08.png]

### 索引存放特点 ###

> 安装过mysql的同学应该都知道 会有一个data文件夹,data文件夹即存放我们的数据

#### myisam ####

(data文件夹下)  
存放着三种格式的文件，它们分别存放的内容：

> .frm文件： 表结构  
> (这些文件存储表的定义信息，包括列名、数据类型等表结构相关信息。)

> .MYD文件：表数据  
> ( 这些文件是MyISAM表的数据文件，存储着实际的行记录和数据内容。)

> .MYI文件： 表索引  
> (这些文件是MyISAM表的索引文件，存储了表的索引信息)

MYI文件的索引其实就是指向数据真实地址的指针  
![在这里插入图片描述][0874bbee233f45979b50b8f737196fda.png]

> 聚集索引：叶节点包含了完整的数据记录

> myisam是非聚集索引(表数据和索引分开存放) 是回表查询,即通过索引，再去.MYD文件中查找数据。

#### InnoDB ####

(data文件夹下)  
存放着两种格式的文件，它们分别存放的内容：

> .frm文件： 表结构  
> (和myisam一样这些文件存储表的定义信息，包括列名、数据类型等表结构相关信息。)

> .idb文件 表数据，表索引  
> (InnoDB存储引擎的数据和索引都存储在共享的数据文件中，通常以.ibd文件的形式存在。.ibd文件包含了表的实际数据以及与之相关的索引信息。)

> innoDB是聚集索引  
> 但在它的二级索引（主键之外的索引）查询操作时，会先查找所在的主键，通过主键再去查找具体数据，也是回表查询。

## 最左原则 ##

联合主键和模糊查询 都遵循最左前缀原则。

在联合主键中，如果由多个列组合而成，那么查询或者排序时会按照主键中列的顺序从左至右依次进行。也就是说，查询或者排序的效率会受到最左边的列的影响，后面的列则会在前面列的基础上进行进一步的筛选。

例如 t 表中，c1 ,c2是联合索引：

> select c1 ,c2 from t where c1 = 1; 这是正确的使用姿势

在模糊查询中，最左原则同样适用，例如 like ‘xx%’ 是可以有效利用索引的 俗称走索引， like '%xx’则不能。

## 主键相关知识点 ##

1.  主键推荐用整型，因为b+tree要比较大小，整型比较快
2.  自增id效率是最高的

那为什么很多项目不用自增id呢？ 自增id两大致命缺点：

1.  不适合分表(分布式系统中不适用)
2.  很容易被猜到相邻数据 （数据隔离问题）

所以一般都是使用雪花算法，而雪花算法常见的（面试）问题就是时钟回溯，正常发生时钟回溯的概率 是可以忽略不计的，百度的算法是直接抛异常 人工处理，美团有解决方案。

## 缓存池 ##

InnoDB缓冲池： InnoDB存储引擎使用缓冲池来缓存数据页和索引页，以加快对数据的访问速度。通过在内存中缓存热门数据，可以减少对物理存储设备的访问次数，从而提高系统的性能和响应速度。

### 淘汰机制 ###

LRU算法：  
InnoDB缓冲池会根据LRU（最近最少使用）算法来管理缓存的数据页，确保内存中始终缓存最常访问的数据。

[fd8b42ebbe8f40d4a4dbaf6ff3255f6e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/8ea24e8533104b218bd07f6e54b15bb6.png
[6a83ef17c41549afbc1790f9f11ad1c7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/8a2eb357964848968a314f20716ccc10.png
[06b2df137b9749a3a953b3831926fb61.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/023aa184fecc47babe9b5a92bf7cb7d0.png
[7043335e6f644365a5b6f0e5a6b1c5b9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/aa5c9a2caef1427a92995312e682ecf3.png
[47bcc104b2744333bb969cf6a2c75a6a.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/53461008693e4da7b28158b6b90c6b73.png
[f46b41dd110944c7aa7291bb7d292a08.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/aa825785779e46f8a43783f857241968.png
[0874bbee233f45979b50b8f737196fda.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/6980c34a15aa46448c0653548ab13a5a.png