一次性将MySQL中的Buffer Pool搞懂
前期回顾
在前面我们学习了Redo Log日志，它的作用说白了，就是保存你的操作，也许你会有这样的疑惑，为什么就Redo Log有一个Buffer在内存中。
Buffer Pol的地位
众所周知，硬盘的速度是非常慢的，而CPU的速度是非常快的，两者的速度天差地别，因此需要固态硬盘作为缓存来缓解两者速度差距过大而出现CPU等待硬盘的情况。所以，对于CPU来说，当它想要对某些数据进行操作的时候，会先把这些数据缓存到内存中，然后在内存中对其进行操作，这样可以提高IO效率，因为不需要在每次读写的时候都去访问磁盘，而Buffer Pool就是用来缓存磁盘文件中的数据的。同理，因为Redo Log是用来记录操作的，所以对它操作的频率基本上和对数据操作的频率一样，如果没有Redo Log Buffer，结果可想而知，因此伴随着Buffer Pool，在内存中也会有一个Redo Log Buffer。
通过上面的讲述，相信你能感觉到Buffer Pool的重要性了，因为对数据的操作都会在Buffer Pool中进行！
Buffer Pool长什么样子？
在MySQL中，Buffer Pool本质上就是个存储数据的数据结构，它的默认总大小是128M，这个默认大小是可以通过命令innodb-buffer-pool-size = xxxxxxx按照需求进行修改的。
那么里面的数据具体是怎么存储的呢？
其实数据都存储在一个个的数据页
那每个数据页是怎么存储数据库中的数据的呢？
中我们都知道，数据库存储有库、表、行和字段的概念，你也许会想，那会不会一个数据页存储一个表的数据呢？很显然这不合理，因为有的表存的数据可能很多，有的表存储的数据也可能很少，这样一来数据页之间的大小可能差距很大。那会不会是一个数据页存储一行数据呢？其实也不是。在说这个之前，我想先给大家说一个对磁盘进行读写时的一个小知识点，对于磁盘文件的读写，是小单位是16k，也就是说，你每次对磁盘进行读操作时假如你想读取的数据是1k大小，但是实际上是16k。我们也知道，数据库中一行数据可能1k都没有，假如你每个数据页存一行数据，但是你每次读取的时候是16k的数据，那岂不是很不合理？因此每个数据页的大小是16k，它里面存储了多行数据。
大致就像下面这样：
缓存页对应的描述信息是什么？
因为我们的增删改操作是对MySQL中的Buffer Pool进行的，为了能够让这种操作像是对MySQL一样，就需要一个专门的数据结构来描述前面提到的数据页——描述数据，它里面包含了表空间号、数据页编号以及数据页在内存中的地址等信息，也是存在MySQL中，其大小大约是缓存页的5%。所以，加入你设置的Buffer Pool大小的128M，实际可能是130M，因为除了存放数据页，还要存放描述信息
像下面这个样子：
数据是如何保存到缓存页中的？
目前我们知道，Buffer Pool被分成了许多个的数据页，那么，当数据从磁盘文件中加载到Buffer Pool中的时候，它是如何知道哪些数据页是恶意存放数据的呢？实际上，每个描述数据内有两个指针，分别是free_pre和free_next，有了这两个指针后，所有的空闲数据页就可以在逻辑上组成一个free双向链表，长得就像下面这个图：
需要注意的是，Free链表中的描述数据和Buffer Pool中的描述数据其实是同一个，只不过在逻辑上他们组成了双向链表。
当有数据从磁盘文件加载到Buffer Pool中的时候，就会从Free链表中找一个描述数据块，将数据放入其对应的缓存页。
怎么知道数据是否已经被缓存了呢？
我们先来回理一下增删改操作，当需要对某个数据进行增删改操作的时候，首先会检查一下，这个数据是否已经在内存中被缓存，如果有的话，那么就直接对内存中的数据进行操作即可，如果缓存中没有，那么就会先从磁盘将数据加载到Buffer Pool中来然后在内存中对其进行操作。
那么我们如何得知我们要的数据是否在已经被缓存了呢？首先，我们要知道的是我们基于内存去找某个数据是否在内存中的时候，其实是在找他所在的数据页是否在内存中，因为每个缓存页都有对应的描述数据。我们知道对于搜索，又很多种方法，比如线性表，树，哈希表等。这里为了达到快速的搜索，采用的是哈希表这一数据结构，K是表空间号+数据页号，V是缓存页的地址，每当你需要查找某个缓存页的时候，都回去这个哈希表中去搜索。
注：这里的表空间号和数据页号都是物理层面的概念，而我们熟知的库，表，行，字段都是逻辑上的概念
脏数据到底是怎回事？
我们知道，MySQL中的Buffer pool是由缓存页组成，然后随着我们不断的增删改，磁盘中的数据也会不断的被夹在到Buffer Pool中，因为Buffer Pool的大小是有限的，肯定是会满的，那万一放不下了该怎么办呢？不难想到的是，MySQL会将某些数据页清空，用来放后面进来的数据，那是不是随便找一个数据页进行清理呢？当然不是，这样太鲁莽了，之前也说过，增删改操作是针对于数据页中的数据，并没有立刻去操作磁盘中的数据。万一数据还没刷入磁盘突然被清理掉了，那肯定会出现这种情况：A修改了某条数据，后面在查询的时候发现竟然还是原来的样子。对于数据页中已经被修改但是还未及时同步到磁盘文件的数据，我们称之为脏数据，他所在的缓存页我们称之为脏页。
如何判断哪些是脏数据呢？
通过刚才的分析，我们知道了脏数据是必须要刷入磁盘的，目的就是使内存中的数据和磁盘中的数据保持一致。但是你想将它们刷入磁盘之前，必须要先知道哪些数据页需要被刷入磁盘，那么MySQL是怎么做的呢？其实呀方法和知道哪些缓存页是空闲的类似，就是让描述数据中有两个指针：flush_pre、flush_next，利用这两个指针在逻辑上组成一个flush链表，一旦某个数据页的数据发生改变，就会将它加入到flush链表中，然后在后台会有专门的IO线程将它们刷入磁盘
当缓存页不够用的时候该怎么办？
上面也分析过了。当缓存页不够用的时候肯定是不会选择清理脏数据页的，那到底应该清理哪些呢？通过上面的分析，我们可以判断的是，被清空的缓存页肯定是没有被修改过的数据，那是不是随机进行清理的呢？在说这个之前，我想先补充个概念——缓存命中率，它指的是在访问缓存的请求的数量在总请求数量的占比，是一个用来判断缓存达到目的的有效依据。命中率越高，从磁盘读取数据的频率就越低，性能也就越好。那么如何提高缓存命中率呢？我们都知道，生活中有一个热搜的概念，对于某些话题，在刚出现的时候讨论很激烈，之后就没多少人说了。对于数据来说，也是如此，有些数据是热点数据，而有些数据则无人问津，并且热点数据被访问的次数肯定很多，既然如此，我们肯定希望的是它能长期的在内存中，这样就会减少很多访问磁盘的操作。新的问题又来了，我们怎么知道那些数据是热点数据呢？和上面讲过的方法也很类似，也是利用双向链表进行记录，但是为了区分热点数据，使用的是LRU链表——Laest Recently Used，意思是最近最少使用。原理也很简单，每当有数据从磁盘中被加载到缓存页的时候，都会将这个缓存页加入到LRU链表的头部，并且当LRU链表中某个数据页被访问的时候，都会将他放到头部，这样一来，经常访问的都会集中在链表前面，处于链表末尾的数据就是最近最少使用的数据了。在内存不够用的时候，就会将其清空掉，用来存放刚加载进来的数据。
今天先更新到这里，先知道Buffer Pool中各种链表的作用，之后的文章，我会去深入一下这其中可能出现的问题，以及其应对方案。
今天先更新到这里，先知道Buffer Pool中各种链表的作用，之后的文章，我会去深入一下这其中可能出现的问题，以及其应对方案。
如果文章中有问题，还望指出，共同进步。写文章不易，如果对你有帮助记得点赞哦~
