一、Buffer Pool初始化
MySQL启动后就会为我们初始化好这块Buffer Pool。如下图:
MySQL以数据页为单位,从磁盘中读取数据。数据页被读取到内存中,所谓的内存其实就是Buffer Pool。
Buffer Pool中维护的数据结构是缓存页,而且每个缓存页都有它对应的描述信息。
由于MySQL刚启动,还没有从磁盘中读取任何数据页到内存(Buffer Pool)中,那此时Buffer Pool中所有的缓存页其实都是空的。
除了缓存页之外,你还能看到Buffer Pool中存在三个双向链表。分别是FreeList、LRUList以及FlushList。这三个双向链表中维护着缓存页的描述信息。
二、一次读取1个数据页
当你通过select读取出一个数据页之后,需要将这个数据页加载进Buffer Pool中的缓存页中。
那问题来了,MySQL怎么知道该将你读取出来的数据页存放在那个缓存页中呢?FreeList这个双向链表不是存放了空闲的缓存页的描述信息吗?那从FreeList中取出一个空间缓存页的描述信息不就好了?于是得到了下面这张图:
InnoDB会将你读取出来的数据页加载进Buffer Pool中的缓存页中,然后缓存页的描述信息也会被维护进LRU链表中。链表做了冷热数据分离优化,5/8的区域是热数据区域,3/8的区域算是冷数据区域。(本质上它们都是双向链表),而你新读取的数据页会被放在冷数据区的靠前的位置上。
如果你将该数据页读取出来加载进缓存页中后,间隔没到1s,就使用该缓存页。那么InnoDB是不会将这个描述信息移动到5/8的热数据区域的。
但是超过1s后,你又去读这个数据页。那这个数据页的描述信息就会被放到热数据区域。如下图:
三、一次读取好多数据页
假设触发了MySQL的预读机制。一次性从磁盘中读取来N多个缓存页。会得到下面这张图:
因为发生了预读,所以一次磁盘IO读出了大量的数据页,但这些数据页中很可能是有一些根本不需要的,仅仅是预读把它们级联查出来了。这时按老规矩,从FreeList中找到空闲的缓存页信息,然后将其从FreeList中移除。根据找到的空闲缓存页的描述信息,将从磁盘中读取出来的数据页加载进去。相应的该缓存页的描述信息也会被维护进LRU链表的冷数据区域。
这时你就会发现这种冷热数据分离的机制多么妙!即使发生了预读又怎么样?根本没有机会将热数据区的描述信息1挤下去。当内存不够用了需要将部分缓存页刷新到磁盘中时,那就从冷数据区域开始刷新好了,反正他们本来就不经常被使用。
同样的,当你超过1s后又访问了冷数据区的缓存页,比如访问了缓存页66和数据页67,该缓存页对应的描述信息是会被提升到热数据区,于是有了下面这张图:
那,如果你访问上图中的数据页67,它会移动到描述信息66所在节点的前面去吗?其实MySQL的LRU链表做了优化,数据67是不会往前跑的。
四、修改某数据页
假设你执行了 update xxx set xxx where id in (xxx,xxx,xxx,xxx);而符合条件的数据行恰巧就在描述信息1、描述信息66、描述信息67所指向的缓存页中,那BufferPool中会发生什么呢?如下图:
你会看到,被修改了的缓存页的描述信息,被添加到了FlushList这个双向链表中。想必看到这里你已经知道了,原来FlushList中的节点存放就是被修改了脏数据页的描述信息块。
随着MySQL被使用的时间越来越长,BufferPool的大小就越来越小。等它不够用的时候,就会将部分LRU中的数据页描述信息移除出去。如果发现被移除出来的数据页在FlushList中,就会触发fsync的操作,触发随机写磁盘。
举个例子:假设需要将描述信息66、描述信息67指向的缓存页落盘。会得到下面这张脑图:
描述信息66、67指向的缓存页被刷新进磁盘。 同时从FlushList中将其移除,然后存入FreeList中。
当然,将脏数据页刷新进磁盘的时机除了上图中说的还有好多种情况,见Flush链表。
