对MySQL底层索引深度解析(1)

2401_83916435

于 2024-04-21 04:27:57 发布

阅读量702

点赞数 8

分类专栏：程序员文章标签： mysql 数据库

本文链接：https://blog.csdn.net/2401_83916435/article/details/138019539

版权

程序员专栏收录该内容

546 篇文章 2 订阅

订阅专栏

哈希表

===

哈希表是一种以键 - 值（key-value）存储数据的结构，我们只要输入待查找的键即 key，就可以找到其对应的值即 Value。哈希的思路很简单，把值放在数组里，用一个哈希函数把 key 换算成一个确定的位置，然后把 value 放在数组的这个位置。

时间复杂度：0(1)

画重点：如果索引的值有重复的话，会发生hash碰撞，虽然可以解决hash冲突，但是导致查询效率降低。
场景：哈希表这种结构适用于只有等值查询的场景，不适用于查找范围的。类似 redis Memcached 及其他一些 NoSQL 引擎。

搜索树

===

在了解搜索树之前我们需要先知道二叉树、平衡二叉树、B树、B+树

推荐一个工具可以清晰的理解树的原理： https://www.cs.usfca.edu/~gal…

二叉树

===

二叉树特性：左子树的键值小于根的键值，右子树的键值大于根的键值。

如下图就是一个二叉树

对MySQL底层索引深度解析

当前二叉树的插入顺序是： 3 2 4 1 5

如果我们按1 2 3 4 5 的顺序来插入的化，我们得到的二叉树就是如下图所示

对MySQL底层索引深度解析

如果是这种二叉树查询效率就太低了。若想二叉树的查询效率尽可能高，需要二叉树是平衡的从而引出新的定义 - 平衡二叉树或称AVL树。

平衡二叉树

=====

平衡二叉树特点：

满足二叉树的特性
任何节点的两个子树的高度最大差为1

如上两个组合之后就是平衡二叉树，如下图

中插入树的顺序为：1 2 3 4 5 6 7 8 时候生成的是如图所示的内容，和图二完成不一样，在通过工具生成这个图的时候明显可以看到不管如何插入节点数据都能满足平衡二叉树的特点2。

当删除一个节点之后同样能满足avl树，如下图删除图3中的5节点之后展示如下。

总结一下平衡二叉树的优点

a 不错的查找性能（O（logn）), 不存在极端的低效查找的情况。
b 可以实现范围查找、数据排序。

看起来 AVL 树作为数据查找的数据结构确实很不错，但是 AVL 树并不适合做 Mysql 数据库的索引数据结构，因为考虑一下这个问题：

数据库查询数据的瓶颈在于磁盘 IO，如果使用的是 AVL 树，我们每一个树节点只存储了一个数据，我们一次磁盘 IO 只能取出来一个节点上的数据加载到内存里，那比如查询 id=8 这个数据我们就要进行磁盘 IO 三次，这是多么消耗时间的。所以我们设计数据库索引时需要首先考虑怎么尽可能减少磁盘 IO 的次数。

磁盘 IO 有个有个特点，就是从磁盘读取 1B 数据和 1KB 数据所消耗的时间是基本一样的，我们就可以根据这个思路，我们可以在一个树节点上尽可能多地存储数据，一次磁盘 IO 就多加载点数据到内存，这就是 B 树，B+树的的设计原理了。

B-树

===

B树的特点：

所有健值分布在整棵树中
搜索有可能在非叶子节点结束
根节点至少有2个子树
所有叶子节点都在同一层
分叉数（路数）永远比关键字数多 1
节点存储key和value

对MySQL底层索引深度解析

演示 B树索引分裂合并

===========

比如 Max Degree（路数）是 3 的时候，我们插入数据 1、2、3，在插入 3 的时候，本来应该在第一个磁盘块，但是如果一个节点有三个关键字的时候，意味着有 4 个指针，子节点会变成 4 路，所以这个时候必须进行分裂。把中间的数据 2 提上去，把 1 和 3 变成 2 的子节点。

如果删除节点，会有相反的合并的操作。注意这里是分裂和合并，跟 AVL 树的左旋和右旋是不一样的。我们继续插入 4 和 5，B Tree 又会出现分裂和合并的操作。

对MySQL底层索引深度解析

从这个里面我们也能看到，在更新索引的时候会有大量的索引的结构的调整，节点的分裂和合并，其实就是 InnoDB 页的分裂和合并。

B+树

===

B+树是在B树上做的一个优化工作

B+树每个节点可以包含更多的节点内容，为什么这么做呢？第一：降低树的高度第二：将数据范围变为多个区间，区间越多检索速度就越快
非叶子节点存的是key, 叶子节点存的是key和数据
叶子节点指针相连，顺序查找速度更快

B 树和 B+树有什么不同呢？

===============

第一，B 树一个节点里存的是key和数据，而 B+树存储的是索引（地址），所以 B 树里一个节点存不了很多个数据，但是 B+树一个节点能存很多索引，B+树叶子节点存所有的数据。

第二，B+树的叶子节点是数据阶段用了一个链表串联起来，便于范围查找。

通过 B 树和 B+树的对比我们看出，B+树节点存储的是索引，在单个节点存储容量有限的情况下，单节点也能存储大量索引，使得整个 B+树高度降低，减少了磁盘 IO。其次，B+树的叶子节点是真正数据存储的地方，叶子节点用了链表连接起来，这个链表本身就是有序的，在数据范围查找时，更具备效率。因此 Mysql 的索引用的就是 B+树，B+树在查找效率、范围查找中都有着非常不错的性能。

综上所述mysql innodb 索引选择了B+树。

思考问题

====

1、B+树叶子节点存的诗所有数据，如果1000万数据，那这个链表太大，不会影响性能吗？

可以利用数据页，下面有重点分析

2、InnoDB一棵B+树可以存放多少行数据？

B+Tree 的根节点和枝节点中都不会存储数据，只有叶子节点才存储数据。搜索到关键字不会直接返回，会到最后一层的叶子节点。比如我们搜索 id=3，虽然在第一层直接命中了，但是全部的数据在叶子节点上面，所以我还要继续往下搜索，一直到叶子节点。

举个例子：假设一条记录是 1K，一个叶子节点（一页）可以存储 16 条记录。非叶子节点可以存储多少个指针？

假设索引字段是 bigint 类型，长度为 8 字节。指针大小在 InnoDB 源码中设置为 6 字节，这样一共 14 字节。非叶子节点（一页）可以存储 1024*16 / 14 = 1170 个这样的单元（键值+指针），代表有 1170 个指针。

树深度为 2 的时候，有 1170^2 个叶子节点，可以存储的数据为：

1170 * 1170 * 16 = 21902400 2000万

在查找数据时一次页的查找代表一次 IO，也就是说，一张 2000 万左右的表，查询数据最多需要访问 3 次磁盘。所以在 InnoDB 中 B+ 树深度一般为 1-3 层，它就能满足千万级的数据存储。