为什么MySQL要设计一个预读机制,为什么有时候要把相邻的一些数据页一次性读入到Buffer Pool缓存里去?
道理很简单,说白了还不是为了提升性能么。假设读取了数据页01到缓存页里去,那么好,接下来有可能会接着顺序读取数据页01相邻的数据页02到缓存页里去,这个时候,是不是可能在读取数据页02的时候要再次发起一次磁盘IO?
所以为了优化性能,MySQL才设计了预读机制,也就是说如果在一个区内,顺序读取了好多数据页了,比如数据页01数据页56都被依次顺序读取了,MySQL会判断,可能接着会继续顺序读取后面的数据页。那么此时就干脆提前把后续的一大堆数据页(比如数据页57数据页72)都读取到Buffer Pool里去,那么后续再读取数据页60的时候,是不是就可以直接从Buffer Pool里拿到数据了?
当然理想是上述那样,很丰满,但是现实可能很骨感。预读的一大堆数据页要是占据了LRU链表的前面部分,可能这些预读的数据页压根儿后续没人会使用,那这个预读机制就是在捣乱了。
基于冷热数据分离的思想设计LRU链表
为了解决简单的LRU链表的问题,真正MySQL在设计LRU链表的时候,采取的实际上是冷热数据分离的思想。真正的LRU链表,会被拆分为两个部分,一部分是热数据,一部分是冷数据,这个冷热数据的比例是由innodb_old_blocks_pct参数控制的,它默认是37,也就是说冷数据占比37%。
这个时候,LRU链表实际上看起来是下面这样子的:
数据页第一次被加载到缓存的时候
首先数据页第一次被加载到缓存的时候,这个时候缓存页会被放在LRU链表的哪个位置呢?
这个时候,缓存页会被放在冷数据区域的链表头部,也就是第一次把一个数据页加载到缓存页之后,这个缓存页实际上是被放在下图箭头的位置,也就是冷数据区域的链表头部位置,如下图所示:
冷数据区域的缓存页什么时候会被放入到热数据区域?
MySQL设定了一个规则,它设计了一个innodb_old_blocks_time参数,默认值1000,也就是1000毫秒。就是说,必须是一个数据页被加载到缓存页之后,在1s之后,你访问这个缓存页,它才会被挪动到热数据区域的链表头部去。因为假设你加载了一个数据页到缓存去,然后过了1s之后你还访问了这个缓存页,说明你后续很可能会经常要访问它,这个时间限制就是1s,因此只有1s后你访问了这个缓存页,它才会给你把缓存页放到热数据区域的链表头部去。
数据加载到缓存页之后过了1s,你再访问这个缓存页,它就会被放入热数据区域的链表头部,如果是你数据刚加载到缓存页,在1s内你就访问缓存页,此时它是不会把这个缓存页放入热数据区域的头部的,如下图所示: