十、InnoDB的Buffer Pool

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

---

前言

InnoDB存存储引擎在处理客户端的请求时，如果需要访问某个页的数据，就把完整的页的数据加载到内存中，也就是说只需要访问一个页的一条记录，也需要把整个页的数据加载到内存中，将整个页的数据加载内存中后就可以进行读写访问了，而且在读写访问之后不着急把该页对应的内存空间释放，而是将页存起来，这样将来有请求再次访问该页面时，就可以省下磁盘I/O的开销
从上面这句话可以获得两个信息：
1、页是磁盘和内存交互的基本单位，哪怕只是读一条数据，也会把该数据对应的页完整的加载到Buffer Pool中
2、页使用完后，不会立马从内存中丢弃，而是暂存在内存中，下一访问时直接使用，减少IO开销

---

一、Buffer Pool

为了缓存磁盘中的页，mysql服务器在启动的时候就向操作系统申请了一块连续的内存空间，这块内存空间就叫做Buffer Pool
默认情况Buffer Pool大小为128mb，可以通过innodb_buffer_pool_size设置大小，但是最小也得5mb，低于5mb会自动设置为5mb

内部组成：
缓冲页：Buffer Pool对应的一片连续的内存空间被划分为若干了页，页的大小也是16kb，我们成这些页为缓冲页
控制块：每个缓冲页都对应一部分控制信息，而且额这部分控制信息大小是相同的，我们把每个页对应的控制信息对应的一块内存称之为控制块。控制块和缓冲页是一一对应的。其中控制块放到Buffer Pool的前面，缓冲页放到后面
碎片： 在分配足够多的控制块和缓冲页后，剩下的一点空间可能不够分配一对控制块和缓冲页的大小，自然就用不到了，这块用不到的内存就叫做碎片。

在debug模式下，每个控制块大概占控制页大小的5%（非debug会更小），因此innodb_buffer_pool_size在申请一块连续的空间作为Buffer Pool时，实际申请单到的会比innodb_buffer_pool_size大5%左右

二 、free链表

最初mysql启动的时候，需要申请一块连续的内存空间，作为Buffer Pool，但是刚开始，这里面是没有数据的，随着程序的进行，才会不断地有页被加入。那么问题来了，从磁盘读取一个页到Buffer Pool中时，该放到哪个缓冲页的位置？或者怎么区分哪个缓冲页是空闲的，哪些已经被使用了？因此必须要记录下哪些缓冲页是可用的，这个时候缓冲页对应的控制块就派上用场了。
把所有空闲的控制页对应的控制块作为一个节点放到链表中，这个链表就是free链表，也称为空闲链表。
刚刚完成初始化的buffer pool中，所有的缓冲页都是空闲的，所以每一个缓冲页的对应的控制块都会加入到free链表

每当从磁盘中读取一个页到Buffer Pool中时，就从free链表中取一个空闲的缓冲页，并把该缓冲页对应的控制块信息填上，然后把该缓冲页对应的free链表节点从链表中移除，表示该缓冲页已经被使用

三、 缓冲页的哈希处理

乍一听可能有点懵，什么是缓冲页的哈希处理？其实是这样的，当我们需要访问某个数据页的内容的时候，首先会判断我们页在Buffer Pool中有没有，没有的话，我们才去磁盘中找，但是Buffer Pool中可能存在很多个缓冲页，哪个是我们想要的呢，如果一个一个遍历是不是效率也太低了，因此在mysql启动的时候，就在内存中维护了一个hash表，当磁盘中的页被加载到Buffer Pool之后，就把表空间号+页号作为key，缓冲页的控制块就作为value。
在需要访问某个数据页的时候，先从hash表中根据表空间+页号看看是否有对应的缓冲页

四、 flush链表

如果我们修改了Buffer Pool中某个缓冲页的数据，这个页就和磁盘上对应的页，就不一样了，这样的缓冲页也叫做脏页。通常我们这么认为的，我们修改了一个页的数据，就得把数据的内容更新到磁盘上，但是我修改一个就更新一个，那岂不是要非常多的io开销？所以每次修改数据页后，我们并不是立刻把缓冲页刷新到磁盘，而是在未来的某个时间进行刷新。Flush链表就是存储脏页的链表，凡是被修改过的缓冲页，它的控制块就会加入到这个链表中，在未来某个时间点会把flush链表对应的脏页更新到磁盘

五 、LRU链表

LRU链表解决的是缓冲区Buffer Pool大小不够的情况：Buffer Pool对应的大小空间是有限的，需要缓存的页占用的内存大小超过了Buffer Pool的大小，也就是说free 链表中，已经没有空闲的缓冲页了，但是我们还要往Buffer Pool中放数据页，这时候就得移除哪些使用不频繁的页，LRU链表就是管理我们的数据页的

1 简单的LRU
当Buffer中不再有空闲的列表时，我们就得淘汰最近很少使用的页，那我们怎么知道哪些是最近频繁使用的页，哪些是不经常使用的页呢？我们可以创建一个链表，由于这个链表是按照最近很少使用的原则去淘汰数据页的，所以这个链表可以称为LRU链表
如果该页不在Buffer Pool中，在把该页从磁盘中加载到Buffer Pool中的缓冲页时，就把该页对应的控制块作为节点塞到LRU链表的头部
如果该页已经被加载到Buffer Pool中，则直接把该页对应的控制块移动到LRU链表的头部
也就说，只要我们使用到某个缓冲页就把某个缓冲页的控制块作为节点放到LRU链表的头部，这样LRU尾部就是最近使用不频繁或者说相对不频繁的页，当空闲的缓冲页用完后，我们就在LRU的尾部找些缓冲页淘汰就好了

2 划分区的LRU链表
1) 简单的LRU链表存在两个问题
问题1——预读
InnoDB提供了一个服务——预读，前面我们说的只有当我们用到某个页的时候，才会将其从磁盘加载到Buffer Pool中，用不到就不加载，所谓预读就是InnoDb认为执行当前的请求，可能在后面读取某些页面，也是就预先把这些页面加载到Buffer Pool中
预读并不是一直发生的，它是由触发机制的，根据触发机制把预读分为：
线性预读：InnoDB提供了一个系统变量innodb_read_ahead_threshold，如果顺序访问某个区的页面超过了这个系统变量值，就会触发异步读取下一个区的全部页到Buffer Pool的请求。注意异步读取意味从磁盘加载这些被预读的页面是，并不影响到当前共工作线程的执行。这个值是可以修改的。
随机预读：如果某个区中13个连续的页面（区中的热页面，头1/4内的）都被加载到了Buffer Pool中，无论这些页面是不是顺序读取的，都会触发一次异步读取本区的所有其他页面到BufferPool中的请求，这个随机预读默认是关闭的，可以通过innodb_random_read_ahead系统变量打开

其实预读本身是一个好事，如果预读带Buffer Pool中的页被成功的使用到，就可以极大地提高语句执行的效率，不过这些预读的页都会放到LRU链表的头部，如果此时Buffer Pool的容量不够大，而且很多预读的页面没有使用到，就会导致处于LRU链表尾部的一些缓冲页会很快被淘汰掉，从而降低Buffer Pool的命中率

问题2——全表扫描
全表扫描意味着把将要访问聚簇索引的全部叶子节点对应的页，如果需要访问的页面特变多，而Buffer Pool又不能全部容纳他们的话，就意味者需要将其他语句在执行过程中用到的页面“排挤”出Buffer Pool，之后在其他语句重新执行时，又得重新从磁盘加载页面到Buffer Pool。
我们在业务中一般不对很大的表执行全表扫描的操作，这是一个很耗时的操作，只有在特定的场景下偶尔对很大的表执行全表扫描操作。由于很大的表执行全表扫描的操作可能要把Buffer Pool中的缓冲页换一次，这会严重影响到其他查询对Buffer Pool的使用，从而降低了Buffer Pool的命中率。

综上可能降低Buffer Pool命中率的两种情况如下：
加载到Buffer Pool中的页不一定被使用到（预读）
如果有非常多的使用频繁偏低的页被同时加载到Buffer pool中，则可能那些使用频繁非常高的页从Buffer Pool中淘汰掉（全表扫描）

2)为了解决上面两个问题，mysql就把LRU链表按照一定比例分成了两截
一部分存储使用频率非常高的缓冲页，这一部分链表也成为热数据，或者称为young 区域
另一部分存储使用频率不是很高的缓冲页，这一部分叫做冷数据，或者称为old区
需要特别注意的是，我们是按照某个比例把LRU链表分成两半的，而不是某些节点固定位于young区，某些节点固定位于old区，随着程序的运行某个节点所属的区域可能发生变化。同时这个比例可以通过innodb_old_blocks_pct修改

3)把LRU链表分区划分怎么解决上述的两个问题的？
1、解决预读：当磁盘上某个缓冲页在初次加载到Buffer Pool中的某个缓冲页时，该缓冲页对应的控制块会放到old区域的头部。这样一来，预读到Buffer Pool却不进行后续访问的页就逐渐从old区域中移除，而不会影响到young区中使用比较频繁的缓冲页
2、解决全表扫描（短时间内访问大量使用频率非常低的页面的优化）
在进行全表扫描时，虽然首次加载到Buffer Pool 中的页放到了Old区域的头部，但是后去会马上被访问到，每次进行访问时，又会把该页放到young区域的头部，这样仍然会把那些使用频率比较高的页面“排挤”下去。有人会想，是否可以在第一次访问该页面时，不将其从old区域移动到young区域的头部，而是在后续再将其移动过去？这是行不通的，这是因为InnoDB中每次去页面读取一条记录时，都算是访问一次页面，而一个页面可能包含很多条记录，也就是说读取完某个页面的记录，就相当于访问了这个页面好几次。
全表扫描有一个特点，就是它的执行频率非常低，而且在进行全表扫描的过程中，即使某个页面有很多条记录，尽管每次读取一条记录都算是访问一次页面，但是这过程所花费的时间是非常少的。所以我们只要规定在某个处于old区域的缓冲页进行第一次访问时，就在它对应的控制块中记录下这个访问时，如果后续的访问的时间与第一次访问的时间在某个时间间隔内，那么该页面就不会从old区域移动到young区域的头部，否则将它们移动到young区域的头部，这个时间间隔是由系统变量 innodb_old_blocks_time 控制的
默认是1000ms，也就是说对于从磁盘加载到LRU链表的old区域的页面来说，如果第一次和最后一次访问该页面的时间间隔小于1S，那么该页是不会加载到young区域的，这就解决的全表扫描带来的问题

3、更进一步优化LRU链表
只有被访问的区域位于young区域的1/4后面时，才会被移动到LRU链表的头部。
其实无论怎么优化都是尽量提高Buffer Pool的命中率

六 刷新脏页到磁盘

Mysql后台有专门的线程负责每隔一段时间就把脏页刷新到磁盘，这样可以不影响用户线程处理正常的请求，刷新方式主要有一下两种：

1、从LRU链表的冷数据中刷新一部分页面到磁盘

2、从flush链表中刷新一部分数据到磁盘

七、多个Buffer Pool实例

Buffer Pool的本质是InnoDB系统申请的一块连续的内存空间，在多线程环境下，访问Buffer Pool中的各种链表需要加锁处理。在Buffer Pool特别大并且多线程并发访问量特别高的请款下，单一的Buffer Pool可能会影响到请求处理速度，所以在Buffer Pool特别大时，可以把他们拆分为若干个小的Buffer Pool，每个Buffer Pool都称为一个实例，它们都是独立的——独立的申请内存空间，独立地管理各种链表。。。。在多线程并发访问时不会相互影响，从而提高了并发处理能力，通过innodb_buffer_pool_instances 的值来修改Buffer Pool实例的个数
那每个Buffer Pool占用的空间就是Buffer Pool的总大下除以实例个数
但是当innodb_buffer_pool_size值小于1G时，设置多少个实例都是无效的，InnoDB会默认把innodb_buffer_pool_instances设置为1。
2个Buffer Pool就是这样：

八 、innodb_buffer_pool_chunk_size

mysql 5.7.5版本之前，只能在服务器启动时通过配置innodb_buffer_pool_size启动选项来调整Buffer Pool的大小；在服务器启动过程中时不允许调整该值的。不过在5.7.5以及版本之后，支持在服务器运行时调整Buffer Pool大小的功能。但是有一个问题，就是每次调节Buffer Pool大小时，都需要向操作系统申请一块连续的内存空间，然后将旧Buffer Pool中的内容复制到这块新空间；这是极其耗时的。所以，mysql决定不在一次性为某个Buffer Pool实例向操作系统申请一大片连续的内存空间，而是以一个chunk为单位向操作系统申请空间。也就是说Buffer Pool其实是由若干个chunk组成的。一个chunk就代表一个连续的内存空间，里面包含了若干了缓冲页与其对应的控制块。

图中的Buffer pool 有两个实例组成，每个实例又包含两个chunk。
有了chunk的存在，我们就可以在运行期间动态的增加或删除空间。
默认一个chunk的大小时128MB，可以通过innodb_buffer_pool_chunk_size在启动时修改，但是一旦修改后，运行期间就不能再修改了