MySQL——buffer poll

为什么要有buffer poll？

如果没有buffer poll，每次读取数据的时候都是从磁盘上读的，这样效率是很差的的。 所以有了提高效率的方式，就加上了一个缓存——buffer poll

所以，当我们读取数据的时候就有以下的方式

• 当读取数据的时候，如果buffer poll中有，就直接返回给用户
• 如果buffer poll中没有，就需要将数据所在的页设置为脏页，然后由后台的线程将脏页读取到磁盘上

buffer poll有多大

在MySQL启动的时候，会向操作系统申请一片内存为buffer poll，默认是128MB。
当然，这个配置是可以通过innodb_buffer_poll_size参数设置

buffer poll中的页

InnoDB会把存储的数据划分为一个个页，每个页的大小都是16KB，而buffer poll中的页就叫做缓存页

什么是脏页、空闲页、干净页

• 空闲页：buffer poll中没有用到的页
• 干净页：buffer poll中的页数据和磁盘上的一样
• 脏页：buffer poll中的页数据和磁盘上的不一样

如何管理空闲页、干净页、脏页？

• Free List：只管理空闲页
• LRU List：管理干净页和脏页
• Flush List：只管理脏页

• Free List：管理空闲的页，当执行查询操作的时候，如果对应的也在buffer poll中就直接返回，如果不在buffer poll中，但Free List不为空，则从磁盘查询对应的数据并且保存到Free List的某个页中，然后将这个页从Free List中移除并放入到LRU List中。
• LRU List：管理所有从磁盘读取的页，包含了未被修改和已经修改的页，并根据LRU算法进行维护和淘汰。
• Flush List：当LRU List中的页被修改后会被标识为脏页，并把脏⻚加⼊到Flush List 中，在这种情况下，数据库会通过刷盘机制把 Flush List中的脏⻚刷回磁盘

Flush List是一个专门用来管理脏页的列表， 而LRU List是用来管理buffer poll中页的可用性。Flush List ⽤来管理要被刷回磁盘的⻚，⼆者互不影响。 Flush List 中的脏⻚在执⾏了刷盘操作后会将空间还给Free List

内存这么多数据页，如何快速找到目标页呢？

• 第一种方式就是遍历链表，这显然不可取，时间复杂度达到了O（N）
• 第二种方式就是InnoDB采取的方式，用page Hash的方式，也就是每当磁盘将数据页加载到内存的时候，用数据的页空间ID和页号作为KEY，当前页的地址作为VALUE保存起来，每次查询时通过key来找到对应的value,从而快速找到对应的目标页。 时间复杂度是O（1）

脏页什么时候被刷盘呢？

首先我们要知道当修改数据的时候，先修改的是buffer poll所在的页，并标记为脏页，但是此时磁盘还是原来的数据。所以在刷盘前会采用WAL技术，即先写入日志，再写入磁盘。

这样的方式即使MySQL宕机了，也可以通过redo log重新恢复数据。
以下是刷盘时机：

• 当redo log满了后，会将脏页刷入到磁盘中
• buffer poll空间不足时，会淘汰数据页，如果是脏页就会进行刷盘
• 由后台进程在空闲的时候自动进行刷盘

buffer poll是通过什么方式淘汰数据的？

buffer poll的大小是有限的，难免就有可能buffer poll满了，需要淘汰掉一部分数据。而我们当然希望频繁访问的数据在buffer poll，淘汰掉哪些不经常访问的数据，这就保证了buffer poll可以继续缓存新的数据了。

所以，有了LRU算法。
算法思想：链表头部的数据是最新被访问的，而链表后面的数据是最久未被访问的。那么当空间不足的时候，就要淘汰掉哪些最久未被使用的数据了。

所以当我们访问数据的时候，有两种结果：

• 如果访问的数据在链表上，就将它放到LRU链表的头部
• 如果没有在链表上，就需要将页放到链表的头部，并且淘汰掉LRU链表最后的节点。

比如下图，假设LRU链表长度为5，LRU链表从左到右有 1 2 3 4 5的页

如果访问了3号的页，就需要将3号放到LRU链表的头部

如果访问的8号的页，因为8号页不在buffer poll中，所以需要将8号页放到LRU链表的头部，并且淘汰掉5号页

但是MySQL没有采用这种方式，因为这种方式会带来两个问题

• 预读失效
• buffer poll污染

什么是预读失效？

预读失效：要知道CPU在加载数据的时候，是一块一块存储的，因为相邻的数据可能会在短时间访问到，所以MySQL在加载数据的时候，会将它相邻的数据加载进来，目的就是为了减少磁盘IO。

但是，这些被加载进来的数据是有可能没有被访问的，这就导致了预读失效。

如何解决预读失效问题？

所以为了解决上面的问题，MySQL将LRU算法改进，将LRU链表划分为了2个区域，一个是young区，一个是old区，例如下图

划分了2个区域后，预读的数据页就会放到old区域，不会放到young区域，只有真正的被访问的使用，会插入到young区域的头部，如果预读的页一直没有被访问就会从old区域中移除。

这样就解决了预读失效的问题，但是还有一个就是buffer poll污染问题没有被解决。

什么是buffer poll污染？

当某个SQL语句需要扫描大量的数据，并且buffer poll内存有限的情况下，可能会将buffer poll里的所有数据全部替换出去，导致大量的热点数据失效了。 当再次被访问的时候，就会造成大量的磁盘IO，性能下降，这就是buffer poll污染。

如何解决buffer poll污染的问题？

MySQL为了解决buffer poll污染的问题，将old区域添加了一个时间判断
如果访问的时间在第一次访问的时间间隔内，那么不会将这个数据页从old区域放到young区域，如果不在第一次访问的时间间隔内，就会将该数据页从old渔区放到young区域。 这样就解决了buffer poll污染的问题。

参考资料：

• https://xiaolincoding.com/mysql/buffer_pool/buffer_pool.html#%E4%B8%BA%E4%BB%80%E4%B9%88%E8%A6%81%E6%9C%89-buffer-pool
• https://blog.csdn.net/error044/article/details/131036148?ops_request_misc=%257B%2522request%255Fid%2522%253A%25223ee1266dddf32eb5972cab120fac8f71%2522%252C%2522scm%2522%253A%252220140713.130102334…%2522%257D&request_id=3ee1266dddf32eb5972cab120fac8f71&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2_blogsobaiduend~default-2-131036148-null-null.nonecase&utm_term=buffer%20poll&spm=1018.2226.3001.4450