InnoDB原理篇：聊聊数据页变成索引这件事

Posted 2022-03-13 程序猿阿星

其实数据页还未写入数据时，是没有数据行的，只有空闲空间，一旦写入，空闲空间会减少一些，直到空闲空间耗尽，具体过程如下图

数据页满了，自然需要开辟新的数据页出来存储数据。

但是随着数据页多起来，它们怎么知道上一页与下一页在那呢？

其实在数据页文件头中存放了特别多的信息，如当前页号、页类型、所属表空间、上一页号、下一页号等等。

所以数据页是通过上下页号，组成双向链表，如下图所示

数据页内部会存储一行一行的数据，每一行数据都会按照主键大小进行排序存储，同时每一行数据都有指针指向下一行数据，组成单向链表。

这个料就是数据页目录部分，数据页目录存储的内容就是主键ID和行位置。

这样就可以通过数据页目录走二分查找，快速定位到数据页内的数据行。

如果只有一个数据页，倒没啥问题，哪有成千上万个数据页呢，还是得一个一个进数据页，搜索数据页目录。

有没有觉得，这似乎是在做全表扫描？

没错，在没有索引的情况下，数据库就是这样执行的。

在说索引之前，先说个前置知识，索引的核心基础要求后一个数据页的主键值都大于前面一个数据页的主键值，如果你的主键是自增的，可以保证这一点。

索引页，顾名思义，就是存储索引信息的数据页，在数据页的文件头部，有页类型来进行区分。

索引页会存储两类内容，一类是最小主键值与索引页号，另一类是最小主键值与数据页号。

把大量的索引信息分散在多个索引页中，再将多个索引页组建成B+树结构，方便二分查找，结构如下图

一直说InnoDB的索引是用B+树来组成的，其实就是这个意思，当然真实的B+树不长这样，这样画还是为了帮助大家理解。

现在整个搜索过程就十分简单了

根据主键id二分查找索引页

找到对应索引页，再二分查找数据页

进入数据页，二分查找数据页目录，找到对应的行数据

写到这里就结束了，通过数据页到最后的索引，体会这个优化的过程，才是本文的重点，由于篇幅有限，索引的内容后面会单独讲解。

程序猿，公众号  「程序猿阿星」 定期分享有趣有料的精品原创文章！

公众号后台回复

回复"all"--领取100余本后端书籍

回复"mj"--领取大厂面试资料

回复"算法"--领取算法学习资料

回复"001"--领取Spring Cloud Alibaba笔记资料

关注公众号

有趣、深入、直接

与你聊聊技术

- END -

InnoDB原理篇：为什么使用索引会变快？

前言

大家好，我是阿星。

本文就接上一篇文章【InnoDB原理篇：聊聊数据页变成索引这件事】来聊聊索引。

建议看完上篇文章再看本篇，食用效果最佳。

索引

假设给你一本非常厚的《Java编程思想》阅读，没有目录，你想快速找到某一个章节的知识点，那估计得找一会了，如果有目录就不一样。

索引其实就是为了提高数据查询的效率，就像书的目录一样，对于数据库的表而言，索引其实就是它的目录。

二叉搜索树

索引的实现种类繁多，比如常见的有序数组、哈希表、树等，不同的结构都有自己的适用场景和局限性，在数据库领域中，树结构是被广泛使用。

我们先从最基本的二叉搜索树说起。

二叉搜索树的特点是：父节点左子树所有结点的值小于父节点的值，右子树所有结点的值大于父节点的值，如下图所示

如果要查id=4的数据，按照图中的搜索顺序是索引页A -> 索引页B -> 索引页D -> 数据页0，时间复杂度是O(log(N))。

也就是说，搜索速度与高度有关，树越高，性能越差，假设100万行的表，使用二叉树来存储，树高20，磁盘每次随机读一个数据块需要10ms左右，单独访问一个行可能需要20个10ms的时间，这个查询可真够慢的。

N叉搜索树

为了减少磁盘随机读IO，就必须控制好树的高度，那就不应该使用二叉树，而是使用N叉树，这里的N代表数据块的大小。

也就说，你一个索引页存储的数据越多，树会越矮，InnoDB中就使用了B+树来实现索引。

以InnoDB的整数字段建立索引为例。

一个页默认16kb,整数（bigint）字段的长度为8B，另外还跟着6B的指向其子树的指针，这意味着一个索引页可以存储接近1200条数据(16kb/14B ≈ 1170)。

如果这颗B+树高度为4，就可以存1200的3次方的值，差不多17亿条数据。

考虑到树根节点总是在内存中的，树的第二层很大概率也在内存中，所以一次搜索最多只需要访问2次磁盘IO。

可能小伙伴会有疑问，为什么树的根节点与树的第二层会在内存，第三层、第四层却没在？

道理很简单，看下数据大小就清楚了

• 树的根节点就是16kb的索引页，内存完全可以放下，里面存储1200条索引目录
• 树的第二层总共是1200个索引页，1200 * 16KB = 20M内存依然放得下的
• 树的第三层1200 * 1200 = 144w页，144w * 16kB = 23G放内存就不合适了
• 树的第四层就是数据页了，属于完整数据了，更不可能全部加载进内存了

最后再感受下索引搜索的流程。

假设1亿数据量的表，根据主键id建立了B+树索引，现在搜索id=2699的数据，流程如下

• 内存中直接获取树根索引页，对树根索引页内的目录进行二分查找，定位到第二层的索引页
• 内存中直接获取第二层的索引页，对索引页内的目录进行二分查找，定位到第三层的索引页
• 从磁盘加载第三层的索引页到内存中，对索引页内的目录进行二分查找，定位到第四层数据页
• 从磁盘加载第四层的数据页到内存中，数据页变成缓存页，对缓存页中的目录进行二分查找，定位到具体的行数据

截止到这里，本文差不多结束了，索引剩余的内容会有后续篇幅讲解。

MySQL好文推荐

• CURD这么多年，你有了解过MySQL的架构设计吗？
• 浅谈 MySQL InnoDB 的内存组件
• 聊聊redo log是什么？
• 不会吧，不会吧，还有人不知道 binlog ？
• redo log与binlog间的破事
• InnoDB原理篇：Buffer Pool为了让MySQL变快都做了什么
• InnoDB原理篇：聊聊数据页变成索引这件事

关于我

阿星是一个热爱技术的 Java 程序猿，公众号 「程序猿阿星」 定期分享有趣有料的精品原创文章！