15张图搞定MySQL InnoDB工作原理，通过五轮面试斩获offer阿里实习生亲述

大家都知道，从磁盘上读写数据，至少需要两次IO请求才能完成。一次是读IO，另一次是写IO 需要zi料+ 绿色徽【vip1024b】

。

而IO请求是比较耗时的操作，如果频繁的进行IO请求势必会影响数据库的性能。

那么，如何才能解决数据库的性能问题呢？

1.2 内存

======

把数据存在寄存器？

没错，操作系统从寄存器中读取数据是最快的，因为它离CPU最近。

但是寄存器有个非常致命的问题是：它只能存储非常少量的数据，设计它的目的主要是用来暂存指令和地址，并非存储大量用户数据的。

这样看来，只能把数据存在内存中了。

因为内存同样能满足我们，快速读取和写入数据的需求，而且性能是非常可观的，只是比较寄存器稍稍慢了一丢丢而已。

不过有个让人讨厌的地方是，内存相对于磁盘来说，是更加昂贵的资源。通常情况下，500G或者1T的磁盘，是很常见的。但你有听说过有500G的内存吗？别人会以为你疯了。内存大小讨论的数量级一般是16G或32G。

内存可以存储一些用户数据，但无法存储所有的用户数据，因为如果数据量太大了，它可能还是存不下。

此外，即使用户数据能刚好存在内存，以后万一有一天，数据库服务器或者部署节点挂了，或者重启了，数据不就丢了？

怎么做，才能不会因为异常情况，而丢数据。同时，又能保证数据的读写速度呢？

2.数据页

=====

我们可以把一批数据放在一起。

写操作时，先将数据写到内存的某个批次中，然后再将该批次的数据一次性刷到磁盘上。如下图所示：

读操作时，从磁盘上一次读一批数据，然后加载到内存当中，以后就在内存中操作。如下图所示：

将内存中的数据刷到磁盘，或者将磁盘中的数据加载到内存，都是以批次为单位，这个批次就是我们常说的：数据页。

当然innodb中存在多种不同类型的页，数据页只是其中一种，我们在这里重点介绍一下数据页。

那么问题来了，什么是数据页？

数据页主要是用来存储表中记录的，它在磁盘中是用双向链表相连的，方便查找，能够非常快速得从一个数据页，定位到另一个数据页。

很多时候，由于我们表中的数据比较多，在磁盘中可能存放在多个数据页当中。

有一天，我们要根据某个条件查询数据时，需要从一个数据页找到另一个数据页，这时候的双向链表就派上大用场了。磁盘中各数据页的整体结构如下图所示：

通常情况下，单个数据页默认的大小是16kb。当然，我们也可以通过参数：innodb_page_size，来重新设置大小。不过，一般情况下，用它的默认值就够了。

好吧，数据页的整体结构已经搞明白了。

那么，单个数据页包含哪些内容呢？

从上图中可以看出，数据页主要包含如下几个部分：

• 文件头部

• 页头部

• 最大和最小记录

• 用户记录

• 空闲空间

• 页目录

• 文件尾部

3.用户记录

======

对于新申请的数据页，用户记录是空的。当插入数据时，innodb会将一部分空闲空间分配给用户记录。

用户记录是innodb的重中之重，我们平时保存到数据库中的数据，就存储在它里面。那么，它里面又包含哪些内容呢？你不好奇吗？

其实在innodb支持的数据行格式有四种：

1. compact行格式

2. redundant行格式

3. dynamic行格式

4. compressed行格式

我们以compact行格式为例：

一条用户记录主要包含三部分内容：

1. 记录额外信息，它包含了变长字段、null值列表和记录头信息。

2. 隐藏列，它包含了行id、事务id和回滚点。

3. 真正的数据列，包含真正的用户数据，可以有很多列。

下面让我们一起了解一下这些内容。

3.1 额外信息

========

额外信息并非真正的用户数据，它是为了辅助存数据用的。

3.1.1 变长字段列表

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

有些数据如果直接存会有问题，比如：如果某个字段是varchar或text类型，它的长度不固定，可以根据存入数据的长度不同，而随之变化。

如果不在一个地方记录数据真正的长度，innodb很可能不知道要分配多少空间。假如都按某个固定长度分配空间，但实际数据又没占多少空间，岂不是会浪费？

所以，需要在变长字段中记录某个变长字段占用的字节数，方便按需分配空间。

3.1.2 null值列表

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

数据库中有些字段的值允许为null，如果把每个字段的null值，都保存到用户记录中，显然有些浪费存储空间。

有没有办法只简单的标记一下，不存储实际的null值呢？

答案：将为null的字段保存到null值列表。

在列表中用二进制的值1，表示该字段允许为null，用0表示不允许为null。它只占用了1位，就能表示某个字符是否为null，确实可以节省很多存储空间。

3.1.3 记录头信息

===========

记录头信息用于描述一些特殊的属性。

它主要包含：

• deleted_flag：即删除标记，用于标记该记录是否被删除了。

• min_rec_flag：即最小目录标记，它是非叶子节点中的最小目录标记。

• n_owned：即拥有的记录数，记录该组索引记录的条数。

• heap_no：即堆上的位置，它表示当前记录在堆上的位置。

• record_type：即记录类型，其中：0表示普通记录，1表示非叶子节点，2表示Infrimum记录， 3表示Supremum记录。

• next_record：即下一条记录的位置。

3.2 隐藏列

=======

数据库在保存一条用户记录时，会自动创建一些隐藏列。如下图所示：

目前innodb自动创建的隐藏列有三种：

• db_row_id，即行id，它是一条记录的唯一标识。

• db_trx_id，即事务id，它是事务的唯一标识。

• db_roll_ptr，即回滚点，它用于事务回滚。

如果表中有主键，则用主键做行id，无需额外创建。如果表中没有主键，假如有不为null的unique唯一键，则用它做为行id，同样无需额外创建。

如果表中既没有主键，又没有唯一键，则数据库会自动创建行id。

也就是说在innodb中，隐藏列中事务id和回滚点是一定会被创建的，但行id要根据实际情况决定。

3.3 真正数据列

=========

真正的数据列中存储了用户的真实数据，它可以包含很多列的数据。这个比较简单，没有什么好多说的。

3.4 用户记录是如何相连的？

总结：绘上一张Kakfa架构思维大纲脑图（xmind）

其实关于Kafka，能问的问题实在是太多了，扒了几天，最终筛选出44问：基础篇17问、进阶篇15问、高级篇12问，个个直戳痛点，不知道如果你不着急看答案，又能答出几个呢？

若是对Kafka的知识还回忆不起来，不妨先看我手绘的知识总结脑图（xmind不能上传，文章里用的是图片版）进行整体架构的梳理

梳理了知识，刷完了面试，如若你还想进一步的深入学习解读kafka以及源码，那么接下来的这份《手写“kafka”》将会是个不错的选择。

• Kafka入门

• 为什么选择Kafka

• Kafka的安装、管理和配置

• Kafka的集群

• 第一个Kafka程序

• Kafka的生产者

• Kafka的消费者

• 深入理解Kafka

• 可靠的数据传递

• Spring和Kafka的整合

• SpringBoot和Kafka的整合

• Kafka实战之削峰填谷

• 数据管道和流式处理(了解即可)

以及源码，那么接下来的这份《手写“kafka”》将会是个不错的选择。

• Kafka入门

• 为什么选择Kafka

• Kafka的安装、管理和配置

• Kafka的集群

• 第一个Kafka程序

• Kafka的生产者

• Kafka的消费者

• 深入理解Kafka

• 可靠的数据传递

• Spring和Kafka的整合

• SpringBoot和Kafka的整合

• Kafka实战之削峰填谷

• 数据管道和流式处理(了解即可)

[外链图片转存中…(img-bGGr3flo-1710341887834)]

[外链图片转存中…(img-ELb2ALrO-1710341887835)]