MySQL十六：36张图理解Buffer Pool

转载~

在应用系统中，我们为加速数据访问，会把高频的数据放在「缓存」(Redis、MongoDB)里，减轻数据库的压力。
在操作系统中，为了减少磁盘IO，引入了「缓冲池」(buffer pool)机制。
MySQL作为一个存储系统，为提高性能，减少磁盘IO，同样具有「缓冲池」(buffer pool)机制。在之前的文章《InnoDB的存储结构》中介绍了InnoDB的存储结构的组成，结构图如下：

「上述结构图中展示了Buffer Pool作为InnoDB内存结构的四大组件之一，不属于MySQL的Server层，是InnoDB存储引擎层的缓冲池」。因此这个跟MySQL8.0删掉的【查询缓存】功能是不一样的。

一、什么是Buffer Pool

「Buffer Pool即【缓冲池，简称BP】，BP以Page页为单位，缓存最热的数据页(data page)与索引页(index page)，Page页默认大小16K，BP的底层采用链表数据结构管理Page」。

上图描述了Buffer Pool在innoDB中的位置，通过它所在的位置我们可以大概知道它的工作流程：

所有数据页的读写操作都需要通过buffer pool进行，

innodb 读操作，先从buffer_pool中查看数据的数据页是否存在，如果不存在，则将page从磁盘读取到buffer pool中。
innodb 写操作，先把数据和日志写入 buffer pool 和 log buffer，再由后台线程以一定频率将 buffer 中的内容刷到磁盘，「这个刷盘机制叫做Checkpoint」。

写操作的事务持久性由redo log 落盘保证，buffer pool只是为了提高读写效率。

「Buffer Pool缓存表数据与索引数据，把磁盘上的数据加载到缓冲池，避免每次访问都进行磁盘IO，起到加速访问的作用」。

Buffer Pool是一块内存区域，是一种「降低磁盘访问的机制」。
数据库的读写都是在buffer pool上进行，和undo log/redo log/redo log buffer/binlog一起使用，后续会把数据刷到硬盘上。
Buffer Pool默认大小 128M，用于缓存数据页（16KB）。
```
show variables like 'innodb_buffer%';
```

Buffer Pool 是 innodb的数据缓存，除了缓存「索引页」和「数据页」，还包括了 undo 页，插入缓存、自适应哈希索引、锁信息等。

「buffer pool绝大多数page都是 data page（包括index page）」。

「innodb 还有日志缓存 log buffer，保存redo log」。

二、Buffer Pool的控制块

Buffer Pool中缓存的是数据页，数据页大小跟磁盘默认数据页大小一样（16K），为了更好管理的缓存页，Buffer Pool有一个「描述数据的区域」 ：

「InnoDB 为每一个缓存的数据页都创建了一个单独的区域，记录的数据页的元数据信息，包括数据页所属表空间、数据页编号、缓存页在Buffer Pool中的地址，链表节点信息、一些锁信息以及 LSN 信息等，这个区域被称之为控制块」。

「控制块和缓存页是一一对应的，它们都被存放到 Buffer Pool 中，其中控制块被存放到 Buffer Pool 的前边，缓存页被存放到 Buffer Pool 后边」，

控制块大概占缓存页大小的5%，16 * 1024 * 0.05 = 819个字节左右。

上图展示了控制块与数据页的对应关系，可以看到在控制块和数据页之间有一个碎片空间。

这里可能会有疑问，为什么会有碎片空间呢？

上面说到，数据页大小为16KB，控制块大概为800字节，当我们划分好所有的控制块与数据页后，可能会有剩余的空间不够一对控制块和缓存页的大小，这部分就是多余的碎片空间。如果把 Buffer Pool 的大小设置的刚刚好的话，也可能不会产生碎片。

三、Buffer Pool的管理

「Buffer Pool里有三个链表，LRU链表，free链表，flush链表，InnoDB正是通过这三个链表的使用来控制数据页的更新与淘汰的」。

3.1 Buffer Pool的初始化

「当启动 Mysql 服务器的时候，需要完成对 Buffer Pool 的初始化过程，即分配 Buffer Pool 的内存空间，把它划分为若干对控制块和缓存页」。

「申请空间」

Mysql 服务器启动，就会根据设置的Buffer Pool大小（innodb_buffer_pool_size）超出一些，去操作系统「申请一块连续内存区域」作为Buffer Pool的内存区域。

这里之所以申请的内存空间会比innodb_buffer_pool_size大一些，主要是因为里面还要存放每个缓存页的控制块。
「划分空间」

当内存区域申请完毕之后，数据库就会按照默认的缓存页的16KB的大小以及对应的800个字节左右的控制块的大小，在Buffer Pool中划分「成若干个【控制块&缓冲页】对」。

划分空间后Buffer Pool的缓存页是都是空的，里面什么都没有，当要对数据执行增删改查的操作的时候，才会把数据对应的页从磁盘文件里读取出来，放入Buffer Pool中的缓存页中。

3.2 Free链表

「在Buffer pool刚被初始化出来的时候，里面的数据页以及控制块都是空的」，当执行读写的时候磁盘的数据页会加载到Buffer pool的数据页中，当BufferPool中间有的页数据持久化到硬盘后，这些数据页又会被空闲出来。

以上的过程中会有一个问题，如何知道那些数据页是空的，那些是有数据的，只有找到空的数据页，才能吧数据写进去，一种方式是遍历所有的数据页，根据经验，一般只要是全部遍历，对于一个有追求的码农肯定是不能忍的，innoDB的开发者无疑更加不能忍，所以就有了free链表。

3.2.1 Free链表是个啥

「Free链表即空闲链表，是一个双向链表，由一个基础节点和若干个子节点组成，记录空闲的数据页对应的控制块信息」。如下

Free链表作用：帮助找到空闲的缓存页
「基节点」
- 「是一块单独申请的内存空间（约占40字节）。并不在Buffer Pool的连续内存空间里」。
- 包含链表中子节点中头节点地址，尾节点地址，以及当前链表中节点的数量等信息。
「子节点」
- 「每个节点就是个空闲缓存页的控制块，即只要一个缓存页空闲，那它的控制块就会被放入free链表」
- 每个控制块块里都有两个指针free_pre（指向上一个节点），free_next（指向下一个节点）

Free链表存在的意义就是描述Buffer Pool中的数据页，所以Free链表跟数据页的是一一对应的关系，如下图所示：

上图就是Free链表记录空闲数据页的对应关系，这里可能会有一个误区，以为这个控制块，在Buffer Pool里有一份，在free链表里也有一份，似乎在内存里有两个一模一样的控制块，「如果这么想就大错特错了」。

「误区说明」

「free链表本身其实就是由Buffer Pool里的控制块组成的，前文中说到每个控制块里都有free_pre/free_next两个指针，分别指向自己的上一个free链表的节点，以及下一个free链表的节点。」

「Buffer Pool中的控制块通过两个指针，就可以把所有的控制块串成一个free链表。上面为了画图看起来更加清晰，所以把free链表单独画了一份出来，表示他们之间的指针引用关系。」

「基于此，真正的关系图应该下图」：

这里之所以会把两个图都画画出来，是因为网上很多博客画的图都是类似上面哪一种，「会给人产生在Buffer Pool和free链表各有一个控制块的误区」，我在开始的时候也产生了这样的疑问，所以在这里说明记录一下。

3.2.2 磁盘页加载到BufferPool的缓存也流程

通过free链表只需要三步就可以将磁盘页加载到BufferPool的缓存中：

「步骤一」

「从free链表中取出一个空闲的控制块以及对应缓冲页」。
「步骤二」

「把磁盘上的数据页读取到对应的缓存页，同时把相关的一些描述数据写入缓存页的控制块（例如：页所在的表空间、页号之类的信息）」。

「步骤三」

「把该控制块对应的free链表节点从链表中移除，表示该缓冲页已经被使用了」。

下面用一个伪代码来描述一下控制块是如何在free链表节点中移除的，假设控制块的结构如下

/**
 *  控制块
 */
publicclass CommandBlock {
    /**
     *  控制块id,也就是自己，可以理解为当前控制块的地址，
     */
    private  String blockId;
    /**
     *  Free链表中当前控制块的上一个节点地址
     */
    private  String freePre;
    /**
     *  Free链表中当前控制块的下一个节点地址
     */
    private  String freeNext;
}

假设有一个控制块n-1，他的上一个节点是描述数据块n-2，下一个节点是描述数据块n，则它的数据结构如下：

/**
 *  控制块 n-1
 */
publicclass CommandBlock {
    /**
     *  控制块id,也就是自己，可以理解为当前控制块的地址 block_n-1，
     */
    blockId = block_n-1;
    /**
     *  Free链表中当前控制块的上一个节点地址 block_n-2
     */
    freePre = block_n-2;
    /**
     *  Free链表中当前控制块的下一个节点地址 block_n
     */
    freeNext = block_n;
}

上图我们使用了控制块N，要从free链表中移除，则只需要把block_n-1中的freeNext设置为null即可， block_n就失去了链表的引用了。

/**
 *  控制块 n-1
 */
publicclass CommandBlock {
    /**
     *  控制块id,也就是自己，可以理解为当前控制块的地址 block_n-1，
     */
    blockId = block_n-1;
    /**
     *  Free链表中当前控制块的上一个节点地址 block_n-2
     */
    freePre = block_n-2;
    /**
     *  Free链表中当前控制块的下一个节点地址 block_n
     */
    freeNext = null;
}

3.2.3 如何确定数据页是否被缓存

了解了磁盘页是通过Free加载到Buffer Pool 的缓存页的过程，不能所有的数据都去磁盘读取然后通过Free链表写入缓存页中，有可能在缓存页中已经有了这个数据页了，那么怎么确定应不应该去缓存数据页呢？

「数据库提供了一个数据页缓存哈希表，以表空间号+数据页号作为key，缓存页控制块的地址作为value」。

#注意：value是控制块的地址，不是缓存页地址
{表空间号+数据页号:控制块的地址}

当使用数据页时，会先在数据页缓存哈希表中查找，如果找到了，则直接根据value定位控制块，然后根据控制块找到缓存页，如果没有找到，则读取磁盘数据页写入缓存，最后写入数据页缓存哈希表。

「在这个过程中一条语句要执行，大致会经历以下几个过程」：

通过sql语句中的数据库名和表名可以知道要加载的数据页处于哪个表空间。
「根据表空间号，表名称本身通过一致性算法得到索引根节点数据页号」。
进而根据根节点数据页号，找到下一层的数据页，可以从数据页缓存哈希表得到对应缓存页地址。
通过缓存页地址就可以在Buffer Pool池中定位到缓存页。

重点误区！！！重点误区！！！重点误区！！！

重要的事情说三遍：

上面说的一致性哈希算法「指在数据字典中【根节点的页号，不是当前查找的数据的数据页号】」，当我们得到根节点页号后，通过B+tree一层一层往下找，在找下一层之前会通过数据缓存哈希表去buffer pool里面看看这个层的数据页存不存在，不存在则去磁盘加载。

「下文所有的图解都是查找buffer pool的过程，不包含索引的树状结构的查找」

流程图如下：

3.3 LRU链表

了解LRU链表之前，我们先来考虑两个问题：

第一个问题：前面说到当从磁盘中读取数据页到Buffer Pool的时候，会将对应的控制块从Free链表中移除，那这个控制块移除之后被放到哪里去了呢？
第二个问题：Buffer Pool的大小是128MB，当Buffer Pool中空闲数据页全部别加载数据之后，新的数据要怎么处理呢？

以上两个问题都需要LRU链表来解决，下面带着这两个问题来看看LRU链表。

3.3.1 LRU链表是个啥

Buffer pool 作为一个innodb自带的一个缓存池，数据的读写都是buffer pool中进行的，操作的都是Buffer pool中的数据页，但是Buffer Pool 的大小是有限的（默认128MB），所以对于一些频繁访问的数据是希望能够一直留在 Buffer Pool 中，而一些访问比较少的数据，我们希望能将它够释放掉，空出数据页缓存其他数据。

「基于此，InnoBD采用了LRU（Least recently used）算法，将频繁访问的数据放在链表头部，而不怎么访问的数据链表末尾，空间不够的时候就从尾部开始淘汰，从而腾出空间」。

「LRU链表本质上也是有控制块组成的」。

3.3.2 LRU链表的写入过程

「当数据库从磁盘加载一个数据页到Buffer Pool中的时候，会将一些变动信息也写到控制块中，并且将控制块从Free链表中脱离加入到LRU链表中」。过程如下：

梳理一下整个过程：

「步骤一：根据表空间号，表名称本身通过一致性算法得到数据页号(这里省略了树状查找过程)」
「步骤二：通过数据页缓存哈希表判断数据页是否被加载」
「步骤三：从Free链表中获取一个控制块」
「步骤四：读取磁盘数据」
「步骤六：将数据写到空闲的缓存页中」
「步骤七：将缓存页的信息写回控制块」
「步骤八：将回控制块从Free链表中移除」
「步骤九：将从Free中移除的控制块节点加入到LRU链表中」

3.3.3 LRU链表的淘汰机制

「LRU算法的设计思路就是：链表头部的节点是最近使用的，链表末尾的节点是最久没被使用的，当空间不够的时候就淘汰末尾最久没被使用的节点，从而腾出空间」。

「LRU算法的目的就是为让被访问的缓存页能够尽量排到靠前的位置」。

「LRU 算法的设计思路」
- 当访问的页在 Buffer Pool 里，就将该页对应的控制块移动到 LRU 链表的头部节点。
- 当访问的页不在 Buffer Pool 里，除了要把控制块放入到 LRU 链表的头部，还要淘汰 LRU 链表末尾的节点。
「LRU 的实现过程」
- 有一次数据访问，访问了数据页23，数据页23不在Buffer Pool 里，因此在磁盘加载之后会将末尾的22号页淘汰，然后将23加载到链表的头部。
- 此时，数据页7被访问了，因为数据页7就在链表中，也就是页在 Buffer Pool 里，所以直接将数据页7移动到链表的头部即可。
- 如下图， LRU 链表长度为 22，节点分别为1到22的数据页控制块，初始状态如下

以上就是LUR链表的实现过程，但是这种方式对于MySQL来说会有问题，所以MySQL并没有直接使用LRU链表的简单实现，而是对其做了一些改进，具体做了哪些改进，我们在下文中继续解释。

3.4 Flush链表

前面解释了我们「对数据的读写都是先对Buffer Pool中的缓存页进行操作，然后在通过后台线程将脏页写入到磁盘，持久化到磁盘中，即刷脏」。

「脏页：当执行写入操作时，先更新的是缓存页，此时缓存页跟磁盘页的数据就会不一致，这就是常说的脏页」。

既然产生了脏页，那就是需要更新磁盘，也就是常说的刷脏，那如何确定那些缓存页需要刷脏呢？也不能吧所有的缓存页都重新刷新一百年磁盘，或者挨个遍历比对，这种方式肯定是不可取的，此时就需要Flush链表了。

3.4.1 Flush链表是个啥

「Flush链表与Free链表的结构很类似，也由基节点与子节点组成」。

Flush链表是一个双向链表，链表结点是被修改过的缓存页对应的控制块（更新过的缓存页）
Flush链表作用：帮助定位脏页，需要刷盘的缓存页
「基节点」：和free链表一样，链接首尾结点，并存储了有多少个描述信息块
「子节点」
- 「每个节点是脏页对应的控制块，即只要一个缓存页被修改，那它的控制块就会被放入Flush链表」
- 每个控制块块里都有两个指针pre（指向上一个节点），next（指向下一个节点）

「前面说了控制块其实是在Buffer Pool中的，控制块是通过上下节点的引用，组成一个链表，所以只需要通过基节点挨个遍历子节点，找到需要刷脏的数据页即可」。

3.4.2 Flush链表写入过程

当我们在写入数据的时候，我们知道磁盘IO的效率很慢，所以MySQL不会直接更新直接更新磁盘，而是经过以下两个步骤：

第一步：更新Buffer Pool中的数据页，一次内存操作；
第二步：将更新操作顺序写Redo log，一次磁盘顺序写操作；

这样的效率是最高的。顺序写Redo log，每秒几万次，问题不大。

上图中描述了在更新数据页的时候，Flush链表的写入过程，其实这只是在被更新的数据已经别加载到Buffer Pool的前提下，如果我们要更新的数据没有别预先加载，那这个过程是不是会先去读取磁盘呢？实际上并不会，MySQL为了提高性能，减少磁盘IO，做了很多的优化，当数据页不存在Buffer Pool中的时候，会使用写缓冲(change buffer)来做更新操作，具体的实现原理下一篇文章再展开解释。

「当控制块被加入到Flush 链表后，后台线程就可以遍历 Flush 链表，将脏页写入到磁盘」。

3.5 Buffer Pool 的数据页

上述了解了三种链表以及它们的使用方式，我们可以总结一下，「其实Buffer Pool 里有三种数据页页和链表来管理数据」。

Free Page（空闲页）

表示此数据页未被使用，是空的，其控制块位于 Free 链表；
「Clean Page（干净页）」

表示此数据页已被使用，缓存了数据，其控制块位于LRU 链表。
「Dirty Page（脏页）」

表示此数据页【已被使用】且【已经被修改】，数据页中数据和磁盘上的数据已经不一致。

当脏页上的数据写入磁盘后，内存数据和磁盘数据一致，那么该页就变成了干净页。

「脏页的控制块同时存在于 LRU 链表和 Flush 链表」。

四、MySQL对LRU算法的改进

在前文中我们说到了简单的LRU算法会对于MySQL来说会有问题，因此MySQL对LRU算法进行了改进，接下来就来看看LRU算法存在什么问题，MySQL又是怎么改进的。

先来说说LRU 算法存在的问题：

「预读失效」
「Buffer Pool 污染」

4.1 什么是预读

既然LRU 算法存在预读失效的问题，先来看看什么是预读。

前面说到，为了减少磁盘IO，innoDB会把数据从磁盘读取到内存中使用，一般而言，数据的读取会遵循【集中读写】的原则，也就是当我们使用一些数据的时候，很大概率也会使用附件的数据，即【局部性原理】，它表明提前加载是有效的，能够减少磁盘IO。因此：

「磁盘数据读取到内存，并不是按需读取，而是按页读取，一次至少读一页数据（16K），如果未来要读取的数据就在页中，直接读取内存即可，不需要磁盘IO，提高效率」。这也就是常说的「预读」。

通过预读我们就可以事先先把数据读取放在内存中，下面来看一下「buffer pool的工作流程图」:

buffer pool的工作流程图中以查询id为1的用户数据为例，大致可以分为三步：

第一步：先查询buffer pool是否存在对应的数据页，有的话则直接返回
第二步：buffer pool不存在对应的数据页，则去磁盘中查找，并把结果copy一份到buffer pool中，然后返回给客户端
第三步：下次有同样的查询，就可以直接查找buffer pool返回数据

例如：当id=1与id=2都在这个数据页中，那么下次查询Id=2的时候，就可以直接通过buffer pool返回。

这个过程看起来，感觉buffer pool跟缓存很类似，实际上它的缓存淘汰机制也跟Redis很类似。

4.2 什么是预读失效

解释了什么是预读，那预读失效就很好理解了，「那些被提前加载进来的数据页并一直没有被访问，相当于预读是白费功夫，即预读失效」。

「通过简单的LRU链表的实现过程我们知道，预读的数据会被放到 LRU 链表头部，而当 Buffer Pool空间不够的时候，需要把末尾的页淘汰掉。如果这些预读的数据一直没有被使用，而把被使用的数据挤到了链表的尾部，进而被淘汰，那缓存的命中率就会大大降低」。这样的话，预读就适得其反了。

4.3 如何提高缓存的命中率

预读的数据被使用到的时候，会减少磁盘IO，但是预读失效的时候，也会降低缓存的命中率，不能因为预读失效，而将预读机制去掉，所以我们要在保留预读这个机制的前提下提高缓存的命中率。

前面将在LRU链表的时候就解释了我们在读到数据之后，把对应的数据页放到LRU链表头部，因此想要提高缓存的命中率，只需要「让真正被访问的页才移动到 LRU 链表的头部，使其在 Buffer Pool 里停留的时间尽可能长，尽可能缩短预读的页停留在 Buffer Pool 里的时间」。

「提高缓存的命中率」

MySQL基于这种设计思路对LRU 算法进行了改进，将 LRU 划分了 2 个区域：

「划分old和young两个区域后，预读的页会被加入到 old 区域的头部，当页被真正访问的时候，才将页插入 young 区域的头部」。

如果预读的页一直没有被访问，会一直存在old 区域，直到被移除，不会影响 young 区域中的热点数据。
- 「old 区域」：在LRU 链表的后半部分
- 「young 区域」：在 LRU 链表的前半部分
  
  「old 区域占整个 LRU 链表长度的比例可以通过 innodb_old_blocks_pc 参数来设置，默认是 37，代表整个 LRU 链表中 young 区域与 old 区域比例是 63:37」。
```
show variables like '%innodb_old_blocks_pc%';
```
「提高缓存的命中率案例说明」
- 紧接着23号页被读取了，那么此时23号页就会被加入到young 区域的头部，而18号页则会被移动到Old区域的头部，这个过程不会有数据页被淘汰。
  
  如果数据页23一直没有被读取，它就会一直存在于Old区，直到其他预读数据加载，慢慢将它淘汰。
- 假设现在有一个数据页23被预读到Buffer Pool中了，那23号页会被加载到old 区域头部，而old区域末尾的22号页会被淘汰掉
- 还是以刚才LRU链表长度为 22，节点分别为1到22的数据页控制块为案例，划分区域后初始状态如下：

由此可见，通过对LRU区域的划分，可以很多好的解决了预读失效的问题，提高了提高缓存的命中率。

4.4 什么是Buffer Pool 污染

预读失效的问题解决了，接下来看看什么是Buffer Pool 污染。

我们知道当Sql执行的时候，「会数据加载到Buffer Pool ，而Buffer Pool的大小是有限的，如果加载大量数据，就会将Buffer Pool 里的所有页都替换出去，导致原本的热数据被淘汰」。下次访问的时候，又要重新去磁盘读取，导致数据库性能下降，这个过程就是「Buffer Pool 污染」。

「什么时候会加载大量数据呢」
- SQL 语句扫描了大量的数据，并返回。
- 对大表进行全表扫描，比如：
```
select * from user where name like "%星河";
select * from user where id+1 = 6
```
  这两个sql 会导致索引失效而走全表扫描，导致全量加载数据到Buffer Pool中
「Buffer Pool加载大量数据」
- 从磁盘读取数据页加入到 LRU 链表的 old 区域头部
- 从数据页中读取行记录进行where进行匹配，这个过程会访问数据页，也就会将数据页加入到 young 区域头部。
- 由于是全表扫描，「因此所有数据都会被按照逐个加入young 区域头部，从而替换淘汰原有的 young 区域数据」。

4.5 如何解决Buffer Pool污染

「Buffer Pool污染跟预读失效都是一样的会导致LRU的热点数据被替换和淘汰」，接下来看看如何解决Buffer Pool 污染而导致缓存命中率下降的问题？

「问题分析」

其实我们可以针对以上全表扫描的情况进行分析，

全表扫描之所以会替换淘汰原有的LRU链表young 区域数据，主要是因为我们将原本只会访问一次的数据页加载到young 区。

这些数据实际上刚刚从磁盘被加载到Buffer Pool，然后就被访问，之后就不会用，基于此，我们是不是可以将数据放young 区的门槛提高有点，从而吧这种访问一次就不会用的数据过滤掉，把它挡在Old区，这样就不会污染young 区的热点数据了。
「解决Buffer Pool污染方案」

MySQL 解决方式就是提高了数据从Old区域进入到 young 区域门槛：

「先设定一个间隔时间innodb_old_blocks_time，然后将Old区域数据页的第一次访问时间在其对应的控制块中记录下来」。

这样看，其实「这个间隔时间innodb_old_blocks_time就是数据页必须在 old 区域停留的时间」。
- 如果后续的访问时间与第一次访问的时间「小于innodb_old_blocks_time」，则「不将该缓存页从 old 区域移动到 young 区域」。
- 如果后续的访问时间与第一次访问的时间「大于innodb_old_blocks_time」，才「会将该缓存页移动到 young 区域的头部」。

show variables like '%innodb_old_blocks_time%';

如上，innodb_old_blocks_time默认是 1s。

即：「当同时满足「数据页被访问」与「数据页在 old 区域停留时间超过 1 秒」两个条件，才会被插入到 young 区域头部」。

通过这种方式，就过滤了上述那种全表扫描导致的将只会访问一次的数据页加载到young 区造成的Buffer Pool 污染的问题。

「young 区域优化」

MySQL为了防止 young 区域节点频繁移动到头部，对 young 区域也做了一个优化：

「young 区域前面 1/4 被访问不会移动到链表头部，只有后面的 3/4被访问了才会」。
- 当访问前面4个数据页时（比如3号数据页），并不会将数据页移动到young 区的头部
- 当访问8号数据页，由于8数据页在后 3/4的young 区，所以8号会被移动到头部
- 比如访问如下LRU链表，young 区域一共有18个数据页，当我们访问young 区的数据页时：

五、脏页的刷盘时机

通过对上述三种链表的描述，我们知道「当我们对数据进行修改时，其实修改的是Buffer Pool 中数据所在缓存页，修改后将其设置为脏页，并将脏页的控制块同时存在于 LRU 链表和 Flush 链表」。然后通过刷脏将修改同步至磁盘。

刷脏不是每次修改都进行的，那样性能会很差，因此刷脏是通过一定的时机触发进行批量刷盘的。

脏页的刷盘时机总的来说就分为以下种：

redo log 日志满了的情况下，会主动触发脏页刷新到磁盘；
MySQL 正常关闭之前，会把所有的脏页刷入到磁盘；
Buffer Pool 空间不足时，会淘汰一部分数据页，如果淘汰的是脏页，需要先将其同步到磁盘。
MySQL 空闲时，后台线程会定期脏页刷盘

下面主要来看一下Buffer Pool 空间不足和后台线程的脏页刷盘过程

5.1 Buffer Pool内存不足触发刷脏

「刷脏的目的是将修改的数据同步磁盘，释放Buffer Pool内存空间」。因此我们肯定是需要将访问的最少的数据页刷会磁盘，释放其数据页内存。

「基于这样的原则，我们只需要根据LRU链表，将其Old区域尾部节点输盘即可」。

我们在前面的描述中已经说了「对于修改的数据页的控制块同时存在于 LRU 链表和 Flush 链表，对于只有读取访问的数据页的控制块存在于 LRU 链表」。

如上图，Buffer Pool内存不足脏页刷盘分为两种情况：

「若缓存页同时在flush链表和lru链表中，说明数据被修改过，则需要刷脏，释放掉缓存页的内存，将控制块重新添加到free链表中」。
「若缓存页只是存在于LRU链表中，说明数据没有被修改过，则不需要刷脏，直接释放掉缓存页的内存，将控制块重新添加到free链表中」。

5.2 后台线程会定期脏页刷盘

为了避免缓冲池内存不够，MySQL在后台有一个定时任务，通过单独的后台线程，不断从LRU链表Old区尾部的缓存页刷回至磁盘中并同时释放缓存页。

六、多实例Buffer Pool

通过上述的描述我们知道：「Buffer Pool本质是InnoDB向操作系统申请的一块连续的内存空间」。

既然是内存空间，那么在多线程环境下，为保证数据的安全性，访问Buffer Pool中的数据都需要加锁处理。

6.1 什么是多实例Buffer Pool

「当多线程并发访问量特别高时，单一的Buffer Pool可能会影响请求的处理速度。因此当Buffer Pool的内存空间很大的时候，可以将单一的Buffer Pool拆分成若干个小的Buffer Pool，每个Buffer Pool都称为一个独立的实例，各自去申请内存空间以及管理各种链表」。以此保证在多线程并发访问时不会相互影响，从而提高并发处理能力。

「innodb_buffer_pool_instances」

通过设置「innodb_buffer_pool_instances的值来修改Buffer Pool实例的个数，默认为1，最大可以设置为64」。
```
show variables like '%innodb_buffer_pool_instances%';
```
```
[server]
innodb_buffer_pool_instances = 2
```
如上配置表示创建2个buffer pool实例（缓冲池总量大小不变，即每个buffer pool的大小为原来的一半）
「每个Buffer Pool的内存空间」

「单个缓冲池实际占用内存空间 = 缓冲池大小 ÷ 缓冲池实例的个数，即」 :

「单个缓冲池实际占用内存空间 = innodb_buffer_pool_size ÷ innodb_buffer_pool_instances」
```
[server]
innodb_buffer_pool_instances = 2
```
如上配置表示创建2个buffer pool实例（缓冲池总量大小不变，即每个buffer pool的大小为原来的一半）
由于管理Buffer Pool需要性能开销，因此「并不是实例越多越好」。
在IInnoDB中，「当innodb_buffer_pool_size小于1GB时，innodb_buffer_pool_instances无效」。

当innodb_buffer_pool_size小于1GB，即使设置的innodb_buffer_pool_instances不为1，InnoDB默认也会把它改为1，这也是考虑到多实例管理的性能开销。

6.2 Buffer Pool的配置

我们先来理解一下一个配置项：innodb_buffer_pool_chunk_size

「innodb_buffer_pool_chunk_size」
- 默认值128MB。可以按照1MB的单位进行增加或减小。
- 可以简单的理解成是Buffer Pool的总大小增加或缩小最小单位。
「innodb_buffer_pool_size的调整」

「Buffer Pool的总大小，必须是innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances的倍数」。

当innodb_buffer_pool_size不等于innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances的倍数时，服务器会自动把innodb_buffer_pool_size的值调整为【innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances】结果的整数倍

如果配置

# buffer_pool最小单位为128MB
innodb_buffer_pool_chunk_size=128MB
# Buffer Pool实例的个数为16
innodb_buffer_pool_instances=16
# buffer_pool总大小为3GB
innodb_buffer_pool_size=3GB

由于

innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances =128MB * 16 = 2GB

而2GB 不等于 innodb_buffer_pool_size=3GB

则InnoDB会调整

# InnoDB会调整buffer_pool总大小为4GB
innodb_buffer_pool_size = 4GB

「innodb_buffer_pool_chunk_size的调整」

在服务启动的时候，会进行如下计算，并判断结果调整innodb_buffer_pool_chunk_size的大小：

如果不等式成立：

「innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances > innodb_buffer_pool_size」

则修改：

「innodb_buffer_pool_chunk_size = innodb_buffer_pool_size /innodb_buffer_pool_instances」

例如：如果配置

# buffer_pool最小单位为128MB
innodb_buffer_pool_chunk_size=256MB
# Buffer Pool实例的个数为16
innodb_buffer_pool_instances=16
# buffer_pool总大小为3GB
innodb_buffer_pool_size=3GB

由于

innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances =256MB * 16 = 4GB

而4GB 大于 innodb_buffer_pool_size=3GB