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

二叉树

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

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

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

如下图 : (具体的数字单纯是博主方便鼠标好画 随意举例的)

红黑树

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

那既然会自动旋转了，解决了变成链表的问题 会不会有其它问题呢？答案是肯定的，当数据量大的时候，树的高度就会增加，如下图:

b tree

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

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

这也是博主自认为最通俗的理解了，我们可以借助工具网站来观察:

hash结构

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

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

hash结构的主要两大缺点：

1. 不支持范围查找
2. 极小概率hash冲突

b+ tree

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

索引存放特点

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

myisam

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

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

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

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

MYI文件的索引其实就是指向数据真实地址的指针

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

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（最近最少使用）算法来管理缓存的数据页，确保内存中始终缓存最常访问的数据。