Mysql.索引存储结构演进

数据结构演进你能明白为啥要用B+Tree来存储，其中B树已经结合了部分磁盘读取的特性，现在详细讲解，在逻辑上存储数据和在磁盘上存储树的区别，

Mysql.索引数据结构演进_闲猫的博客-CSDN博客

如果有时间请按照顺序浏览，该顺序是思考的顺序更容易接受

1. 大量数据的持久化需要持久化到磁盘上

2. 磁盘读取速度慢，尽量减少IO次数

3. 读取磁盘单位是块，所以数据能放在一块就不放在两块

4. 如果按照树节点结构为Node(data,next)，挨个读取数据，那么不同节点最坏的情况是在不同块中，如果读取一个块为16k，只使用其中一个Node数据(8B)，是不是很浪费。数据量稍微大一点，树就会很深，那么就得进行多少次IO。

 Node类型：

    A：ID 用来排序的依据

    B：数据域 用来其他数据，对于节点是否存储数据专门讨论，这里暂定是存储数据的

    C：Left节点引用：左子树root节点引用

    D：Right节点引用：右子树root节点引用

5. 如果每次读取必须读取一个磁盘块（操作系统规定，类似Mysql的存储页），那么只有这个磁盘块都是有用的才没有浪费。数据结构上，就用一个磁盘块对于树中的一个Node，这样势必会存储很多组数据。那么节点数据结构如下：

约定术语：

Node，树节点：指的是上面大方块内容

数据，Data，一条数据：指的是上面ID1+数据域

举例说明：假定一个Node只能存储两个数据，三个引用

场景1：查找id=28的用户信息，流程如下： 1. 先找到根节点也就是页1，判断28在键值17和35之间，我们那么我们根据页1中的指针p2找到页3。 2. 将28和页3中的键值相比较，28在26和30之间，我们根据页3中的指针p2找到页8。 3. 将28和页8中的键值相比较，发现有匹配的键值28，键值28对应的用户信息为(28,bv)。

场景2：增加100~110节点，为了平衡需要调整树结构；如果是中间增加数据，调整次数会更多

场景3：删除<35所有的数据，为了平衡需要调整树结构

规律总结：

• 每个块存储的节点越多，高度越低
• 一个固定大小的块(页)存储多少数据，取决于一条数据的大小
• insert最好根据id大小顺序来插入，否则调整结构会导致insert效率很低
• 删除数据同样会调整树结构

 6. 需求：查找ID为[12,29]的数据，是不是不怎么好读取

• 问题：根据二叉查找树查找比较简单，读取就不容易了，总的来说是前序遍历，但只输出满足条件的数据，实现逻辑复杂
• 复杂：子节点没有父节点引用，找不回去，找到12节点和29节点，并不能顺序遍历输出，而是还得遍历全部数据，然后判断是否符合条件，找到容易输出没法子了，这样要索引只能查找单个数据。
• 但如果子节点存储父节点的引用，就可以从12节点开始：12,根据p3找到13,15，然后找到父节点，12已输出，找12的父节点，输出17,17的左子树……。还是很麻烦
• 设想：如果存储数据的结构是列表，找到12直接遍历到17不就可以了。很爽是不是，最终的结果就是 列表 + 树 组合，如下图： 

 说明：

• 树是完全平衡树，叶子节点链起来就是一个链表
• 每个列表Node是一页，每页中有多条数据，这些数据排序
• 非叶子节点不在存储数据，只存储用于排序的ID和引用
• 这样的结构再找[12,29]的数据就好找多了

7.Mysql 索引结构

1. 默认数据块为16K
2. Mysql Innodb B+Tree索引，就是上面结构，叶子节点存储数据。
3. Mysql MyISAM B+Tree索引，类似上面结构，不同的是子节点存储的数据域不是数据，而是地址，需要根据地址再去找完整数据
4. 类似MyISAM B+Tree索引，Innodb B+Tree非聚集索引 叶子节点存储的是ID值，需要根据ID去聚集索引去找数据
5. 加入一个节点可以存储1000个键值，那么3层B+树可以存储1000×1000×1000=10亿个数据。一般根节点是常驻内存的，所以一般我们查找10亿数据，只需要2次磁盘IO。

END