mysql12

最新推荐文章于 2023-11-13 20:54:04 发布

Markland_l

最新推荐文章于 2023-11-13 20:54:04 发布

阅读量250

点赞数 1

分类专栏： mysql 文章标签： java 算法前端

本文链接：https://blog.csdn.net/Markland_l/article/details/125839790

版权

mysql 专栏收录该内容

19 篇文章 0 订阅

订阅专栏

InnoDB引擎底层解析

数据溢出

如果我们定义一个表，表中只有一个 VARCHAR 字段，如下：
- CREATE TABLE test_varchar( c VARCHAR(60000) )
- 然后往这个字段插入 60000 个字符，会发生什么？
前边说过，MySQL 中磁盘和内存交互的基本单位是页，也就是说 MySQL 是以页为基本单位来管理存储空间的，我们的记录都会被分配到某个页中存储。而一个页的大小一般是 16KB，也就是 16384 字节，而一个 VARCHAR(M)类型的列就最多可以存储 65532 个字节，这样就可能造成一个页存放不了一条记录的情况。
在 Compact 和 Redundant 行格式中，对于占用存储空间非常大的列，在记录的真实数据处只会存储该列的该列的前 768 个字节的数据，然后把剩余的数据分散存储在几个其他的页中，记录的真实数据处用 20 个字节存储指向这些页的地址。这个过程也叫做行溢出，存储超出 768 字节的那些页面也被称为溢出页
Dynamic 和 Compressed 行格式，不会在记录的真实数据处存储字段真实数据的前 768 个字节，而是把所有的字节都存储到其他页面中，只在记录的真实数据处存储其他页面的地址。
那发生行溢出的临界点是什么呢？也就是说在列存储多少字节的数据时就会发生行溢出？
MySQL 中规定一个页中至少存放两行记录，以上边的 test_varchar 表为例，它只有一个列 c，==我们往这个表中插入两条记录，每条记录最少插入多少字节的数据才会行溢出的现象呢？==这得分析一下页中的空间都是如何利用的。
每个页除了存放我们的记录以外，也需要存储一些页本身的信息，加起来需要 132 个字节的空间，其他的空间都可以被用来存储记录。每个记录需要的额外信息是 27 字节。
假设一个列中存储的数据字节数为 n，MySQL 规定如果该列不发生溢出的现象，就需要满足下边这个式子：
- 132《页本身的信息》 + 2《一个页至少2条数据》×(27《额外请求头+3个指标》 + n) < 16384
求解这个式子得出的解是：n < 8099。也就是说如果一个列中存储的数据小于 8099 个字节，那么该列就不会成为溢出列，否则该列就需要成为溢出列。不过这个 8099 个字节的结论只是针对只有一个列的 test_varchar 表来说的，如果表中有多个列，那上边的式子和结论都需要改。所以重点就是：这个临界点具体值无关紧要，只要知道如果我们一条记录的某个列中存储的数据占用的字节数非常多时，该列就可能成为溢出列。

索引页格式

前边我们简单提了一下页的概念，它是 InnoDB 管理存储空间的基本单位，一个页的大小一般是
InnoDB 为了不同的目的而设计了许多种不同类型的页，存放我们表中记录的那种类型的页自然也是其中的一员，官方称这种存放记录的页为索引（INDEX）页，不过要理解成数据页也没问题，毕竟存在着聚簇索引这种索引和数据混合的东西。

数据页结构

一个 InnoDB 数据页的存储空间大致被划分成了 7 个部分：
- File Header 文件头部 38 字节页的一些通用信息
- Page Header 页面头部 56 字节数据页专有的一些信息
- Infimum + Supremum 最小记录和最大记录 26 字节两个虚拟的行记录
- User Records 用户记录大小不确定实际存储的行记录内容
- Free Space 空闲空间大小不确定页中尚未使用的空间
- Page Directory 页面目录大小不确定页中的某些记录的相对位置
- File Trailer 文件尾部 8 字节校验页是否完整

User Records

infimum+supremum+user records 是真实数据
- infimum指向排序后第一条记录
- 排序后的第一条记录指向排序后的第二条记录
- 。。。
- 排序后的最后一条记录指向supremum
- 叶子节点存在一个页里面是一个单链表
- 叶子节点包含了所有的元素
- 从根节点到叶子节点的过程是很快的，进入到叶子点后，它所在的页包含的叶子叶子节点是一个单链表，页之间是双链表
当前记录被删除时，则会修改记录头信息中的 delete_mask 为 1，也就是说被删除的记录还在页中，还在真实的磁盘上。这些被删除的记录之所以不立即从磁盘上移除，是因为移除它们之后把其他的记录在磁盘上重新排列需要性能消耗。
所以只是打一个删除标记而已，所有被删除掉的记录都会组成一个所谓的垃圾链表，在这个链表中的记录占用的空间称之为所谓的可重用空间，之后如果有新记录插入到表中的话，可能把这些被删除的记录占用的存储空间覆盖掉。
同时我们插入的记录在会记录自己在本页中的位置，写入了记录头信息中 heap_no 部分。heap_no 值为 0 和 1 的记录是 InnoDB 自动给每个页增加的两个记录，称为伪记录或者虚拟记录。这两个伪记录一个代表最小记录，一个代表最大记录，这两条存放在页的 User Records 部分，他们被单独放在一个称为 Infimum + Supremum 的部分。
记录头信息中 next_record 记录了从当前记录的真实数据到下一条记录的真实数据的地址偏移量。这其实是个链表，可以通过一条记录找到它的下一条记录。但是需要注意注意再注意的一点是，下一条记录指得并不是按照我们插入顺序的下一条记录，而是按照主键值由小到大的顺序的下一条记录。而且规定 Infimum 记录（也就是最小记录）的下一条记录就是本页中主键值最小的用户记录，而本页中主键值最大的用户记录的下一条记录就是 Supremum 记录（也就是最大记录）
我们的记录按照主键从小到大的顺序形成了一个单链表，记录被删除，则从这个链表上摘除。

Page Directory

Page Directory 主要是解决记录链表的查找问题。如果我们想根据主键值查找页中的某条记录该咋办？按链表查找的办法：从 Infimum 记录（最小记录）开始，沿着链表一直往后找，总会找到或者找不到。
InnoDB 的改进是，为页中的记录再制作了一个目录，他们的制作过程是这样的：
- 1、将所有正常的记录（包括最大和最小记录，不包括标记为已删除的记录）划分为几个组。
- 2、每个组的最后一条记录（也就是组内最大的那条记录）的头信息中的 n_owned 属性表示该记录拥有多少条记录，也就是该组内共有几条记录。
- 3、将每个组的最后一条记录的地址偏移量单独提取出来按顺序存储到靠近页的尾部的地方，这个地方就是所谓的 Page Directory，也就是页目录页面目录中的这些地址偏移量被称为槽（英文名：Slot），所以这个页面目录就是由槽组成的。
- 4、每个分组中的记录条数是有规定的：对于最小记录所在的分组只能有 1 条记录，最大记录所在的分组拥有的记录条数只能在 1~8 条之间，剩下的分组中记录的条数范围只能在是 4~8 条之间。如下图：
这样，一个数据页中查找指定主键值的记录的过程分为两步：通过二分法确定该记录所在的槽，并找到该槽所在分组中主键值最小的那条记录。通过记录的 next_record 属性遍历该槽所在的组中的各个记录。

Page Header

InnoDB 为了能得到一个数据页中存储的记录的状态信息，比如本页中已经存储了多少条记录，第一条记录的地址是什么，页目录中存储了多少个槽等等，特意在页中定义了一个叫 Page Header 的部分，它是页结构的第二部分，这个部分占用固定的 56 个字节，专门存储各种状态信息。

File Header

File Header 针对各种类型的页都通用，也就是说不同类型的页都会以 File Header 作为第一个组成部分，它描述了一些针对各种页都通用的一些信息，比方说页的类型，这个页的编号是多少，它的上一个页、下一个页是谁（B+树是双向链表），页的校验和等等，这个部分占用固定的 38 个字节。
页的类型，包括 Undo 日志页、段信息节点、Insert Buffer 空闲列表、Insert Buffer 位图、系统页、事务系统数据、表空间头部信息、扩展描述页、溢出页、索引页，有些页会在后面的课程看到。
同时通过上一个页、下一个页建立一个双向链表把许许多多的页就串联起来，而无需这些页在物理上真正连着。但是并不是所有类型的页都有上一个和下一个页的属性，数据页是有这两个属性的，所以所有的数据页其实是一个双向链表。

File Trailer

我们知道 InnoDB 存储引擎会把数据存储到磁盘上，但是磁盘速度太慢，需要以页为单位把数据加载到内存中处理，如果该页中的数据在内存中被修改了，那么在修改后的某个时间需要把数据同步到磁盘中。但是在同步了一半的时候中断电了咋办？
为了检测一个页是否完整（也就是在同步的时候有没有发生只同步一半的尴尬情况），InnoDB 每个页的尾部都加了一个 File Trailer 部分，这个部分由 8 个字节组成，可以分成 2 个小部分：
前 4 个字节代表页的校验和
这个部分是和 File Header 中的校验和相对应的。每当一个页面在内存中修改了，在同步之前就要把它的校验和算出来，因为 File Header 在页面的前边，所以校验和会被首先同步到磁盘，当完全写完时，校验和也会被写到页的尾部，如果完全同步成功，则页的首部和尾部的校验和应该是一致的。如果写了一半儿断电了，那么在 File Header 中的校验和就代表着已经修改过的页，而在 File Trailer 中的校验和代表着原先的页，二者不同则意味着同步中间出了错。
后 4 个字节代表页面被最后修改时对应的日志序列位置（LSN），这个也和校验页的完整性有关。
这个 File Trailer 与 File Header 类似，都是所有类型的页通用的。

InnoDB 的表空间

表空间是一个抽象的概念，对于系统表空间来说，对应着文件系统中一个或多个实际文件；对于每个独立表空间来说，对应着文件系统中一个名为表名.ibd 的实际文件。大家可以把表空间想象成被切分为许许多多个页的池子，当我们想为某个表插入一条记录的时候，就从池子中捞出一个对应的页来把数据写进去。
再回忆一次，InnoDB 是以页为单位管理存储空间的，我们的聚簇索引（也就是完整的表数据）和其他的二级索引都是以 B+树的形式保存到表空间的，而 B+树的节点就是数据页。
任何类型的页都有 File Header 这个部分，File Header 中专门的地方（FIL_PAGE_ARCH_LOG_NO_OR_SPACE_ID）保存页属于哪个表空间，同时表空间中的每一个页都对应着一个页号（FIL_PAGE_OFFSET），这个页号由 4 个字节组成，也就是 32 个比特位，所以一个表空间最多可以拥有 2³²个页，如果按照页的默认大小 16KB 来算，一个表空间最多支持 64TB 的数据。

独立表空间结构

一个独立表空间对应一个.ibd文件。
File Header里面有个页号，是4字节大小，所以表空间中的页可以达到 2³²个页

区（extent）

表空间中的页可以达到 2³²个页，实在是太多了，为了更好的管理这些页面， InnoDB 中还有一个区（英文名：extent）的概念。对于 16KB 的页来说，连续的 64 个页就是一个区，也就是说一个区默认占用 1MB 空间大小。
不论是系统表空间还是独立表空间，都可以看成是由若干个区组成的，每 256 个区又被划分成一个组。
第一个组最开始的 3 个页面的类型是固定的：用来登记整个表空间的一些整体属性以及本组所有的区被称为 FSP_HDR，也就是 extent 0 ~ extent 255 这 256 个区，整个表空间只有一个 FSP_HDR。
其余各组最开始的 2 个页面的类型是固定的，一个 XDES 类型，用来登记本组 256 个区的属性，FSP_HDR 类型的页面其实和 XDES 类型的页面的作用类似，只不过 FSP_HDR 类型的页面还会额外存储一些表空间的属性。
引入区的主要目的是什么？我们每向表中插入一条记录，本质上就是向该表的聚簇索引以及所有二级索引代表的 B+树的节点中插入数据。而 B+树的每一层中的页都会形成一个双向链表，如果是以页为单位来分配存储空间的话，双向链表相邻的两个页之间的逻辑位置是连在一起，但是物理位置可能离得非常远。
我们介绍 B+树索引的适用场景的时候特别提到范围查询只需要定位到最左边的记录和最右边的记录，然后沿着双向链表一直扫描就可以了，而如果链表中相邻的两个页物理位置离得非常远，就是所谓的随机 I/O。再一次强调，磁盘的速度和内存的速度差了好几个数量级，随机 I/O 是非常慢的，所以我们应该尽量让链表中相邻的页的物理位置也相邻，这样进行范围查询的时候才可以使用所谓的顺序 I/O。
一个区就是在物理位置上连续的 64 个页。在表中数据量大的时候，为某个索引分配空间的时候就不再按照页为单位分配了，而是按照区为单位分配，甚至在表中的数据十分非常特别多的时候，可以一次性分配多个连续的区，从性能角度看，可以消除很多的随机 I/O。

段（segment）

我们提到的范围查询，其实是对 B+树叶子节点中的记录进行顺序扫描，而如果不区分叶子节点和非叶子节点，统统把节点代表的页面放到申请到的区中的话，进行范围扫描的效果就大打折扣了。所以 InnoDB 对 B+树的叶子节点和非叶子节点进行了区别对待，也就是说叶子节点有自己独有的区，非叶子节点也有自己独有的区。存放叶子节点的区的集合就算是一个段（segment），存放非叶子节点的区的集合也算是一个段。也就是说一个索引会生成 2 个段，一个叶子节点段，一个非叶子节点段。
段其实不对应表空间中某一个连续的物理区域，而是一个逻辑上的概念。

系统表空间

整体结构

系统表空间的结构和独立表空间基本类似，只不过由于整个 MySQL 进程只有一个系统表空间，在系统表空间中会额外记录一些有关整个系统信息的页面，所以会比独立表空间多出一些记录这些信息的页面，相当于是表空间之首，所以它的表空间 ID（Space ID）是 0。
系统表空间和独立表空间的前三个页面的类型是一致的，只是页号为 3～7 的页面是系统表空间特有的。分别包括：
- 页号页面类型英文描述描述
- 3 SYS Insert Buffer Header 存储 Insert Buffer 的头部信息
- 4 INDEX Insert Buffer Root 存储 Insert Buffer 的根页面
- 5 TRX_SYS Transction System 事务系统的相关信息
- 6 SYS First Rollback Segment 第一个回滚段的页面
- 7 SYS Data Dictionary Header 数据字典头部信息
系统表空间的 extent 1 和 extent 2 这两个区，也就是页号从 64~191 这 128 个页面被称为 Doublewrite buffer，也就是双写缓冲区。

双写缓冲区/双写机制

双写缓冲区/双写机制是 InnoDB 的三大特性之一，还有两个是 Buffer Pool、自适应 Hash 索引(AHI)。
它是一种特殊文件 flush 技术，带给 InnoDB 存储引擎的是数据页的可靠性。它的作用是，在把页写到数据文件之前，InnoDB 先把它们写到一个叫 doublewrite buffer（双写缓冲区）的连续区域内，在写 doublewrite buffer 完成后，InnoDB 才会把页写到数据文件的适当的位置。如果在写页的过程中发生意外崩溃，InnoDB 在稍后的恢复过程中在 doublewrite buffer 中找到完好的 page 副本用于恢复。
所以，虽然叫双写缓冲区，但是这个缓冲区不仅在内存中有，更多的是属于 MySQL 的系统表空间，属于磁盘文件的一部分。那为什么要引入一个双写机制呢？
InnoDB 的页大小一般是 16KB，其数据校验也是针对这 16KB 来计算的，将数据写入到磁盘是以页为单位进行操作的。而操作系统写文件是以 4KB 作为单位的，那么每写一个 InnoDB 的页到磁盘上，操作系统需要写 4 个块。
而计算机硬件和操作系统，在极端情况下（比如断电）往往并不能保证这一操作的原子性，16K 的数据，写入 4K 时，发生了系统断电或系统崩溃，只有一部分写是成功的，这种情况下会产生 partial page write（部分页写入）问题。这时页数据出现不一样的情形，从而形成一个"断裂"的页，使数据产生混乱。在 InnoDB 存储引擎未使用 doublewrite 技术前，曾经出现过因为部分写失效而导致数据丢失的情况。
doublewrite buffer 是 InnoDB 在表空间上的 128 个页（2 个区，extend1 和 extend2），大小是 2MB。为了解决部分页写入问题，当 MySQL 将脏数据 flush 到数据文件的时候, 先使用 memcopy 将脏数据复制到内存中的一个区域（也是 2M），之后通过这个内存区域再分 2 次，每次写入 1MB 到系统表空间，然后马上调用 fsync 函数，同步到磁盘上。在这个过程中是顺序写，开销并不大，在完成 doublewrite 写入后，再将数据写入各数据文件文件，这时是离散写入。
所以在正常的情况下, MySQL 写数据页时，会写两遍到磁盘上，第一遍是写到 doublewrite buffer，第二遍是写到真正的数据文件中。如果发生了极端情况（断电），InnoDB 再次启动后，发现了一个页数据已经损坏，那么此时就可以从 doublewrite buffer 中进行数据恢复了。
前面说过，位于系统表空间上的 doublewrite buffer 实际上也是一个文件，写系统表空间会导致系统有更多的 fsync 操作, 而硬盘的 fsync 性能因素会降低 MySQL 的整体性能。不过在存储上，doublewrite 是在一个连续的存储空间, 所以硬盘在写数据的时候是顺序写，而不是随机写，这样性能影响不大，相比不双写，降低了大概 5-10%左右。
所以，在一些情况下可以关闭 doublewrite 以获取更高的性能。比如在 slave 上可以关闭，因为即使出现了 partial page write 问题，数据还是可以从中继日志中恢复。比如某些文件系统 ZFS 本身有些文件系统本身就提供了部分写失效的防范机制，也可以关闭。
在数据库异常关闭的情况下启动时，都会做数据库恢复（redo）操作，恢复的过程中，数据库都会检查页面是不是合法（校验等等），如果发现一个页面校验结果不一致，则此时会用到双写这个功能。
有经验的同学也许会想到，如果发生写失效，可以通过重做日志(Redo Log) 进行恢复啊！但是要注意，重做日志中记录的是对页的物理操作，如偏移量 800, 写’ aaaa’记录，而不是页面的全量记录，而如果发生 partial page write（部分页写入）问题时，出现问题的是未修改过的数据，此时重做日志(Redo Log)无能为力。写 doublewrite buffer 成功了，这个问题就不用担心了。
如果是写 doublewrite buffer 本身失败，那么这些数据不会被写到磁盘， InnoDB 此时会从磁盘载入原始的数据，然后通过 InnoDB 的事务日志来计算出正确的数据，重新写入到 doublewrite buffer，这个速度就比较慢了。如果 doublewrite buffer 写成功的话,但是写数据文件失败，innodb 就不用通过事务日志来计算了, 而是直接用 doublewrite buffer 的数据再写一遍，速度上会快很多。
总体来说，doublewrite buffer 的作用有两个: 提高 innodb 把缓存的数据写到硬盘这个过程的安全性；间接的好处就是，innodb 的事务日志不需要包含所有数据的前后映像,而是二进制变化量，这可以节省大量的 IO。

InnoDB 数据字典(Data Dictionary Header)

我们平时使用 INSERT 语句向表中插入的那些记录称之为用户数据，MySQL 只是作为一个软件来为我们来保管这些数据，提供方便的增删改查接口而已。但是每当我们向一个表中插入一条记录的时候，MySQL 先要校验一下插入语句对应的表存不存在，插入的列和表中的列是否符合，如果语法没有问题的话，还需要知道该表的聚簇索引和所有二级索引对应的根页面是哪个表空间的哪个页面，然后把记录插入对应索引的 B+树中。所以说，MySQL 除了保存着我们插入的用户数据之外，还需要保存许多额外的信息，比方说：
某个表属于哪个表空间，表里边有多少列，表对应的每一个列的类型是什么，该表有多少索引，每个索引对应哪几个字段，该索引对应的根页面在哪个表空间的哪个页面，该表有哪些外键，外键对应哪个表的哪些列，某个表空间对应文件系统上文件路径是什么。
上述这些数据并不是我们使用 INSERT 语句插入的用户数据，实际上是为了更好的管理我们这些用户数据而不得已引入的一些额外数据，这些数据也称为元数据。InnoDB 存储引擎特意定义了一些列的内部系统表（internal system table）来记录这些这些元数据：
- 表名描述
- SYS_TABLES整个 InnoDB 存储引擎中所有的表的信息
- SYS_COLUMNS 整个 InnoDB 存储引擎中所有的列的信息
- SYS_INDEXES 整个 InnoDB 存储引擎中所有的索引的信息
- SYS_FIELDS 整个 InnoDB 存储引擎中所有的索引对应的列的信息
- SYS_FOREIGN 整个 InnoDB 存储引擎中所有的外键的信息
- SYS_FOREIGN_COLS 整个 InnoDB 存储引擎中所有的外键对应列的信息
- SYS_TABLESPACES 整个 InnoDB 存储引擎中所有的表空间信息
- SYS_DATAFILES 整个 InnoDB 存储引擎中所有的表空间对应文件系统的文件路径信息
- SYS_VIRTUAL 整个 InnoDB 存储引擎中所有的虚拟生成列的信息
这些系统表也被称为数据字典，它们都是以 B+树的形式保存在系统表空间的某些页面中，其中 SYS_TABLES、SYS_COLUMNS、SYS_INDEXES、SYS_FIELDS 这四个表尤其重要，称之为基本系统表。
这 4 个表是表中之表，那这 4 个表的元数据去哪里获取呢？只能把这 4 个表的元数据，就是它们有哪些列、哪些索引等信息硬编码到代码中，然后 InnoDB 的又拿出一个固定的页面来记录这 4 个表的聚簇索引和二级索引对应的 B+树位置，这个页面就是页号为 7 的页面 Data Dictionary Header，类型为 SYS，记录了数据字典的头部信息。除了这 4 个表的 5 个索引的根页面信息外，这个页号为 7 的页面还记录了整个 InnoDB 存储引擎的一些全局属性，比如 Row ID。
数据字典头部信息中有个 Max Row ID 字段，我们说过如果我们不显式的为表定义主键，而且表中也没有 UNIQUE 索引，那么 InnoDB 存储引擎会默认为我们生成一个名为 row_id 的列作为主键。因为它是主键，所以每条记录的 row_id 列的值不能重复。
原则上只要一个表中的 row_id 列不重复就可以了，也就是说表 a 和表 b 拥有一样的 row_id 列也没啥关系，不过 InnoDB 只提供了这个 Max Row ID 字段，不论哪个拥有 row_id 列的表插入一条记录时，该记录的 row_id 列的值就是 Max Row ID 对应的值，然后再把 Max Row ID 对应的值加 1，也就是说这个 Max Row ID 是全局共享的。
用户是不能直接访问 InnoDB 的这些内部系统表的，除非你直接去解析系统表空间对应文件系统上的文件。不过 InnoDB 考虑到查看这些表的内容可能有助于大家分析问题，所以在系统数据库 information_schema 中提供了一些以 innodb_sys 开头的表：
- INNODB_SYS_DATAFILES
- INNODB_SYS_VIRTUAL
- INNODB_SYS_INDECS
- INNODB_SYS_TABLES
- INNODB_SYS_FIELDS
- INNODB_SYS_TABLESPACCES
- INNODB_SYS_FOREIGN_COLS
- INNODB_SYS_COLUMNS
- INNDOB_SYS_FOREIGN
- INNODB_SYS_TABLESTATS
在 information_schema 数据库中的这些以 INNODB_SYS 开头的表并不是真正的内部系统表（内部系统表就是我们上边唠叨的以 SYS 开头的那些表），而是在存储引擎启动时读取这些以 SYS 开头的系统表，然后填充到这些以 INNODB_SYS 开头的表中.

InnoDB 的 Buffer Pool

缓存的重要性

我们知道，对于使用 InnoDB 作为存储引擎的表来说，不管是用于存储用户数据的索引（包括聚簇索引和二级索引），还是各种系统数据，都是以页的形式存放在表空间中的，而所谓的表空间只不过是 InnoDB 对文件系统上一个或几个实际文件的抽象，也就是说我们的数据说到底还是存储在磁盘上的。
但是磁盘的速度慢，所以 InnoDB 存储引擎在处理客户端的请求时，当需要访问某个页的数据时，就会把完整的页的数据全部加载到内存中，也就是说即使我们只需要访问一个页的一条记录，那也需要先把整个页的数据加载到内存中。将整个页加载到内存中后就可以进行读写访问了，在进行完读写访问之后并不着急把该页对应的内存空间释放掉，而是将其缓存起来，这样将来有请求再次访问该页面时，就可以省去磁盘 IO 的开销了。

Buffer Pool

InnoDB 为了缓存磁盘中的页，在 MySQL 服务器启动的时候就向操作系统申请了一片连续的内存，他们给这片内存起了个名，叫做 Buffer Pool（中文名是缓冲池）。那它有多大呢？这个其实看我们机器的配置，默认情况下 Buffer Pool 只有 128M 大小，这个值其实是偏小的。
- show variables like ‘innodb_buffer_pool_size’;
可以在启动服务器的时候配置 innodb_buffer_pool_size 参数的值，它表示 Buffer Pool 的大小，就像这样：
- [server]
- innodb_buffer_pool_size = 268435456
其中，268435456 的单位是字节，也就是指定 Buffer Pool 的大小为 256M。需要注意的是，Buffer Pool 也不能太小，最小值为 5M(当小于该值时会自动设置成 5M)。
Buffer Pool 内部组成
Buffer Pool 中默认的缓存页大小和在磁盘上默认的页大小是一样的，都是 16KB。为了更好的管理这些在 Buffer Pool 中的缓存页，InnoDB 为每一个缓存页都创建了一些所谓的控制信息，这些控制信息包括该页所属的表空间编号、页号、缓存页在 Buffer Pool 中的地址、链表节点信息、一些锁信息以及 LSN 信息，当然还有一些别的控制信息。-
每个缓存页对应的控制信息占用的内存大小是相同的，我们称为控制块。控制块和缓存页是一一对应的，它们都被存放到 Buffer Pool 中，其中控制块被存放到 Buffer Pool 的前边，缓存页被存放到 Buffer Pool 后边，所以整个 Buffer Pool 对应的内存空间看起来就是这样的：
个控制块大约占用缓存页大小的 5%，而我们设置的 innodb_buffer_pool_size 并不包含这部分控制块占用的内存空间大小，也就是说 InnoDB 在为 Buffer Pool 向操作系统申请连续的内存空间时，这片连续的内存空间一般会比 innodb_buffer_pool_size 的值大 5%左右。

free 链表的管理

最初启动 MySQL 服务器的时候，需要完成对 Buffer Pool 的初始化过程，就是先向操作系统申请 Buffer Pool 的内存空间，然后把它划分成若干对控制块和缓存页。但是此时并没有真实的磁盘页被缓存到 Buffer Pool 中（因为还没有用到），之后随着程序的运行，会不断的有磁盘上的页被缓存到 Buffer Pool 中。
那么问题来了，从磁盘上读取一个页到 Buffer Pool 中的时候该放到哪个缓存页的位置呢？或者说怎么区分 Buffer Pool 中哪些缓存页是空闲的，哪些已经被使用了呢？最好在某个地方记录一下 Buffer Pool 中哪些缓存页是可用的，这个时候缓存页对应的控制块就派上大用场了，我们可以把所有空闲的缓存页对应的控制块作为一个节点放到一个链表中，这个链表也可以被称作 free 链表（或者说空闲链表）。刚刚完成初始化的 Buffer Pool 中所有的缓存页都是空闲的，所以每一个缓存页对应的控制块都会被加入到 free 链表中，假设该 Buffer Pool 中可容纳的缓存页数量为 n，那增加了 free 链表的效果图就是这样的：
- 所有的控制块组成了一个链表
有了这个 free 链表之后，每当需要从磁盘中加载一个页到 Buffer Pool 中时，就从 free 链表中取一个空闲的缓存页，并且把该缓存页对应的控制块的信息填上（就是该页所在的表空间、页号之类的信息），然后把该缓存页对应的 free 链表节点从链表中移除，表示该缓存页已经被使用了。

缓存页的哈希处理

我们前边说过，当我们需要访问某个页中的数据时，就会把该页从磁盘加载到 Buffer Pool 中，如果该页已经在 Buffer Pool 中的话直接使用就可以了。那么问题也就来了，我们怎么知道该页在不在 Buffer Pool 中呢？难不成需要依次遍历 Buffer Pool 中各个缓存页么？
我们其实是根据表空间号 + 页号来定位一个页的，也就相当于表空间号 + 页号是一个 key，缓存页就是对应的 value，怎么通过一个 key 来快速找着一个 value 呢？
所以我们可以用表空间号 + 页号作为 key，缓存页作为 value 创建一个哈希表，在需要访问某个页的数据时，先从哈希表中根据表空间号 + 页号看看有没有对应的缓存页，如果有，直接使用该缓存页就好，如果没有，那就从 free 链表中选一个空闲的缓存页，然后把磁盘中对应的页加载到该缓存页的位置。

flush 链表的管理

如果我们修改了 Buffer Pool 中某个缓存页的数据，那它就和磁盘上的页不一致了，这样的缓存页也被称为脏页（英文名：dirty page）。当然，最简单的做法就是每发生一次修改就立即同步到磁盘上对应的页上，但是频繁的往磁盘中写数据会严重的影响程序的性能。所以每次修改缓存页后，我们并不着急立即把修改同步到磁盘上，而是在未来的某个时间点进行同步。
但是如果不立即同步到磁盘的话，那之后再同步的时候我们怎么知道 Buffer Pool 中哪些页是脏页，哪些页从来没被修改过呢？总不能把所有的缓存页都同步到磁盘上吧，假如 Buffer Pool 被设置的很大，比方说 300G，那一次性同步会非常慢。
所以，需要再创建一个存储脏页的链表，凡是修改过的缓存页对应的控制块都会作为一个节点加入到一个链表中，因为这个链表节点对应的缓存页都是需要被刷新到磁盘上的，所以也叫 flush 链表。链表的构造和 free 链表差不多。

LRU 链表的管理

缓存不够的窘境

Buffer Pool 对应的内存大小毕竟是有限的，如果需要缓存的页占用的内存大小超过了 Buffer Pool 大小，也就是 free 链表中已经没有多余的空闲缓存页的时候该咋办？当然是把某些旧的缓存页从 Buffer Pool 中移除，然后再把新的页放进来，那么问题来了，移除哪些缓存页呢？
为了回答这个问题，我们还需要回到我们设立 Buffer Pool 的初衷，我们就是想减少和磁盘的 IO 交互，最好每次在访问某个页的时候它都已经被缓存到 Buffer Pool 中了。假设我们一共访问了 n 次页，那么被访问的页已经在缓存中的次数除以 n 就是所谓的缓存命中率，我们的期望就是让缓存命中率越高越好。
从这个角度出发，回想一下我们的微信聊天列表，排在前边的都是最近很频繁使用的，排在后边的自然就是最近很少使用的，假如列表能容纳下的联系人有限，你是会把最近很频繁使用的留下还是最近很少使用的留下呢？当然是留下最近很频繁使用的了。

简单的 LRU 链表

管理 Buffer Pool 的缓存页其实也是这个道理，当 Buffer Pool 中不再有空闲的缓存页时，就需要淘汰掉部分最近很少使用的缓存页。不过，我们怎么知道哪些缓存页最近频繁使用，哪些最近很少使用呢？
再创建一个链表，由于这个链表是为了按照最近最少使用的原则去淘汰缓存页的，所以这个链表可以被称为 LRU 链表（LRU 的英文全称：Least Recently Used）。当我们需要访问某个页时，可以这样处理 LRU 链表：
如果该页不在 Buffer Pool 中，在把该页从磁盘加载到 Buffer Pool 中的缓存页时，就把该缓存页对应的控制块作为节点塞到 LRU 链表的头部。如果该页已经缓存在 Buffer Pool 中，则直接把该页对应的控制块移动到 LRU 链表的头部。
也就是说：只要我们使用到某个缓存页，就把该缓存页调整到 LRU 链表的头部，这样 LRU 链表尾部就是最近最少使用的缓存页。所以当 Buffer Pool 中的空闲缓存页使用完时，到 LRU 链表的尾部找些缓存页淘汰就行了。