亲宝软件园·资讯

展开

MySql InnoDB存储引擎之Buffer Pool运行原理讲解

程序员小潘 人气:0

1. 前言

我们已经知道,对于InnoDB存储引擎而言,页是磁盘和内存交互的基本单位。哪怕你要读取一条记录,InnoDB也会将整个索引页加载到内存。哪怕你只改了1个字节的数据,该索引页就是脏页了,整个索引页都要刷新到磁盘。InnoDB是基于磁盘的存储引擎,如果每次操作都去读写磁盘,那么性能将会受到很大的影响。而且绝大多数时候,程序读写的数据在磁盘上并不是连续的,这意味着需要执行大量的随机IO读写,磁盘随机IO读写效率是非常低的,尤其是传统的机械硬盘。

在解决这个问题之前,大家可以先想一想,为什么我们只想读取一条记录,而InnoDB会将整个页的数据都加载到内存?因为根据计算机的局部性原理,程序接下来大概率会访问与它相邻的记录,为了避免频繁发起磁盘IO读操作,InnoDB直接将整个页都加载到内存,下次再访问页中的其它记录时,就可以命中缓存了,减少磁盘IO操作。

问题解决的思路其实是一样的,磁盘的速度虽然很慢,但是内存的速度快啊。这些被加载到内存里的索引页,使用完毕后不要立即释放,而是将它们先缓存下来,下次再访问这些页时,就可以命中缓存了,减少磁盘IO,从而提升性能。理论上,只要内存无限大,那么MySQL几乎可以是基于内存的数据库了。

InnoDB缓存索引页的组件,就是我们今天要聊的「Buffer Pool」。

2. Buffer Pool

MySQL服务器启动时,InnoDB会向操作系统申请一块连续的内存空间用来缓存索引页,这一块连续的内存空间就是Buffer Pool。默认情况下Buffer Pool的大小是128MB,查看命令如下:

mysql> SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| innodb_buffer_pool_size | 134217728 |
+-------------------------+-----------+

理论上,Buffer Pool越大,缓存的索引页就可以更多,缓存的命中率就可以更高,对应的性能提升就越明显。如果你的机器内存够大,完全可以调大 Buffer Pool的大小,在配置文件里进行修改:

[server]
innodb_buffer_pool_size=2147483648
innodb_buffer_pool_instances=2

Buffer Pool最小是5MB,即使你配置的小于5MB,InnoDB也会分配5MB的内存。

innodb_buffer_pool_instances启动项代表Buffer Pool实例的个数。是的,你没看错,Buffer Pool支持配置多个,不同实例之间是隔离的,互不影响。配置多个的主要原因是因为Buffer Pool由多个链表组成,在维护这些链表时需要加锁保证同步,在高并发场景下会影响性能,配置多个实例就可以解决这个问题了。

每个Buffer Pool的大小是innodb_buffer_pool_size/innodb_buffer_pool_instances,InnoDB有规定,单个Buffer Pool实例的大小如果小于1GB,即使配置多个也不会生效。

2.1 Buffer Pool结构

Buffer Pool是用来缓存物理磁盘上的页结构的,那它自然也是由若干个页组成。为了与磁盘上的页区分开,这里我们叫它「缓冲页」。为了更好的管理这些缓冲页,InnoDB为每个缓冲页都创建了一个「控制块」对象与之关联。所以,Buffer Pool其实是由若干对控制块和缓冲页,以及一些碎片空间组成的。

为什么会有碎片空间?如果最后剩余的空间不足以分配一对控制块和缓冲页,就会被浪费掉,也就是碎片空间。除非你把Buffer Pool的大小设置的刚好合适。另外,控制块的大小在正常模式下和DEBUG模式下占用的大小并不一样,DEBUG模式下控制块的大小约为缓冲页的5%。

缓冲页的结构和物理磁盘上的页一致,也就没什么好说的了。控制块主要记录了缓冲页所属的表空间ID、页号、缓冲页在Buffer Pool中的地址、链表节点信息等等。我们重点关注链表节点,因为Buffer Pool出于不同的目的,将这些缓冲页串联成了多条链表,后面会提到。

总之,Buffer Pool的结构其实很简单,如下图所示:

2.2 Free链表

Buffer Pool是用来缓存磁盘上的页结构的,那么第一个问题就来了。当我们要从磁盘上加载一个页的时候,这个页该放到Buffer Pool的哪个缓冲页里呢?总不能遍历整个Buffer Pool吧,哪个缓冲页是空闲的就直接使用它,这未免也太笨拙了。

InnoDB会通过控制块里的链表节点属性,将所有空闲的缓冲页都串联成一条双向链表,叫作「Free链表」。MySQL服务器刚启动时,所有的缓冲页都会加入到该链表中,因为所有的缓冲页都没有被使用。当我们要把磁盘上的页加载到内存时,就从Free链表申请一个缓冲页,并把它对应的控制块从Free链表中移除,这比遍历整个Buffer Pool可高效多了。

怎么找到Free链表呢?为了更好的管理这些链表,InnoDB为每条链表都创建了一个叫作「链表基节点」的结构,它的属性就三个,分别记录链表的头尾节点指针、以及链表内的节点数量。

2.3 缓冲页哈希表

第二个问题又来了,当我们要使用某个页的时候,怎么知道它有没有被加载到Buffer Pool呢?难道又要再遍历一次所有已使用的缓冲页吗?未免也太笨拙了。

在同一个表空间里,每个页都有唯一的一个页号,所以要定位一个页,只需要知道表空间ID+页号就可以了。也就是说,我们完全可以建立一个哈希表,哈希表的Key就是表空间ID+页号的组合,Value就是缓冲页。这样就可以快速判断某个页是否已经加载到Buffer Pool了。

2.4 Flush链表

在执行增删改操作时,如果InnoDB每次都把受影响的页同步到磁盘,那么必然会导致大量的磁盘随机IO写操作,这个效率是很低的。为了提升性能,InnoDB会先在内存里修改这些受影响的页面,这些被修改过的页面称作「脏页」(Dirty Page),然后由一个额外的线程负责将这些脏页刷新到磁盘。

内存断电数据就丢失了,那些没来得及刷盘的脏页岂不是数据就丢失了?不用担心,后面聊的redo log会帮我们保证数据一致性的,这里先跳过。

第三个问题又来了,InnoDB怎么知道哪些页是脏页呢?再遍历一次Buffer Pool吗?太笨拙了,为了解决这个问题,InnoDB又引入了第二条链表:flush链表。

flush链表和free链表极其相似,也有一个链表基节点,当我们修改了缓冲页里的数据,InnoDB就会把该缓冲页对应的控制块加入到flush链表,等待后续的刷盘。

2.5 LRU链表

那些已经被使用的缓冲页,会从Free链表中移除,然后加入到一个叫作“LRU”的链表中。LRU是Least Recently Used的缩写,译为“最近最少使用”。为啥会需要LRU链表呢?说白了,相较于磁盘上海量的数据,Buffer Pool那点内存实在是杯水车薪,当Buffer Pool中的内存不够时,就不得不释放掉一些页面,来缓存新的页面。

Buffer Pool的本质是为了减少磁盘IO的访问,提高缓存命中率,正是因为它小才显得极其珍贵,InnoDB更应该要用好它。如果是你,你会在Buffer Pool里放访问频率高的页面,还是访问频率低的页面呢?

最简单的LRU链表,每当我们要访问一个页面时,就把它移动到LRU链表的表头,那么链尾的页面自然就是最近最少使用的了,当Free链表没有空闲的缓冲页时,直接把LRU链表的链尾页面释放掉即可。看似没什么问题,但是某些场景下,LRU链表会被破坏:

1.全表扫描:全表扫描需要加载聚簇索引B+树的所有叶子节点,当表中数据量较大时,可能一次全表扫描就会把之前访问频率很高的缓冲页全部从LRU链表中挤出,下次再访问这些页面时,又得从磁盘上重新加载一遍了。

2.预读:InnoDB内置了一个贴心的预读功能,它会在执行当前读请求时,判断是否还会访问其它页面,然后异步的把这些页面提前加载到Buffer Pool,从而加速读操作。预读细分为两种:

综上所述,全表扫描和预读可能会破坏LRU链表,本质上就是将大量可能短期不会被访问到的页面加入到LRU链表,反而导致那些访问频率很高的页面被挤掉了,导致Buffer Pool的命中率降低。

为了解决这个问题,InnoDB对LRU链表进行了优化,将LRU链表按照一定的比例分成两部分:存储访问频率很高的Young区、存储访问频率较低的Old区。系统变量innodb_old_blocks_pct控制了Old区所占的比例,默认值是37。也就是说,整个LRU链表的前约5/8部分用来存储访问频率很高的缓冲页,后约3/8部分用来存储访问频率较低的缓冲页。

将LRU链表划分为两截后,InnoDB是这样来维护LRU链表的:首次加载的页面不会直接放到LRU链表的表头,而是Old区的头部,如果该页面后续没有继续访问,会慢慢被释放掉,而不影响Young区的页面。如果后续再次访问了该页面,判断距离上次访问的时间,只有两次访问的时间间隔超过了阈值,才会把它移动到Young区头部。

时间间隔的阈值通过系统变量innodb_old_blocks_time配置,默认是1000ms

LRU链表经过这么一番优化后,我们看看是如何解决上面两个场景的:

对于Young区的缓冲页,如果每访问一次都要把它移动到LRU链表的表头,这个操作未免也太频繁了,因为Young区本来就是访问频率很高的页面,大家互相换来换去意义不大。所以InnoDB再进一步优化,如果访问的缓冲页在Young区的前1/4处,是不需要移动到表头的,只有访问的缓冲页在Young区的后3/4处才会把它移动到表头,这大大降低了链表节点移动的频率。

2.6 多个实例

现在我们知道,Buffer Pool在物理上虽然是一块连续的内存空间,但是逻辑上它由多条链表组成。在维护这些链表时,都需要加锁来保证同步,在高并发场景下,这会带来一些性能上的影响。为了解决这个问题,InnoDB支持多个Buffer Pool实例,每个实例都是独立的,会维护自己的各种链表,多线程并发访问时不会有影响,从而提高并发处理能力。

查看Buffer Pool实例个数的命令,默认是1个。

mysql> SHOW VARIABLES LIKE 'innodb_buffer_pool_instances';
+------------------------------+-------+
| Variable_name                | Value |
+------------------------------+-------+
| innodb_buffer_pool_instances | 1     |
+------------------------------+-------+

支持在配置文件中进行配置:

[server]
innodb_buffer_pool_size=2147483648
innodb_buffer_pool_instances=2

在MySQL5.7.5之前,InnoDB是不支持运行时动态调整Buffer Pool大小的,主要是因为每次调整大小,都需要向操作系统重新申请一个Buffer Pool,然后将数据拷贝一次,这个开销太大了。在之后的版本中,InnoDB引入了chunk的概念来支持运行时修改Buffer Pool大小。一个Buffer Pool实例由若干个chunk组成,里面包含了若干个控制块和缓冲页。在调整Buffer Pool大小时,InnoDB以chunk为单位来申请内存空间和数据的拷贝。

chunk的大小由系统变量innodb_buffer_pool_chunk_size控制,默认是128MB,chunk本身的大小不支持运行时修改。

mysql> SHOW VARIABLES LIKE 'innodb_buffer_pool_chunk_size';
+-------------------------------+-----------+
| Variable_name                 | Value     |
+-------------------------------+-----------+
| innodb_buffer_pool_chunk_size | 134217728 |
+-------------------------------+-----------+

innodb_buffer_pool_size必须是innodb_buffer_pool_chunk_size*innodb_buffer_pool_instances的整数倍大小,目的是保证没个Buffer Pool实例的chunk数量一致。

2.7 Buffer Pool状态信息

说了这么多,耳听为虚,眼见为实。如何查看MySQL运行时的Buffer Pool相关的状态信息呢?命令是SHOW ENGINE INNODB STATUS,输出的是InnoDB引擎的状态信息,其中就包含Buffer Pool的状态信息,如下:

----------------------
BUFFER POOL AND MEMORY
----------------------
Total large memory allocated 137428992
Dictionary memory allocated 268616
Buffer pool size   8191
Free buffers       7238
Database pages     953
Old database pages 371
Modified db pages  0
Pending reads      0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 0, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 919, created 34, written 36
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
Buffer pool hit rate 740 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 959, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]

3. 总结

磁盘速度太慢了,如果每次读取页面都从磁盘加载,会导致大量的磁盘IO随机读,MySQL的性能势必会受到严重影响。为了解决这个问题,InnoDB引入了Buffer Pool,它会在MySQL服务器启动时申请一块连续的内存空间,用来缓存对应的磁盘里的页结构。每个缓冲页都有一个与之关联的控制块,InnoDB为了不同的目的,将这些控制块串联成多条双向链表,例如:Free链表、LRU链表、Flush链表等等。为了提高Buffer Pool的命中率,防止一些特殊的操作破坏LRU链表,InnoDB将LRU链表按照一定的比例划分成两截,分别是存放访问频率很高的页的Young区,和访问频率较低的页的Old区。Buffer Pool逻辑上由这些链表组成,维护这些链表都需要加锁保证同步,高并发下会影响性能,所以InnoDB支持配置多个Buffer Pool实例。为了在运行时支持调整Buffer Pool的大小,InnoDB又引入了chunk的概念,最后通过命令我们可以查看Buffer Pool的状态信息。

加载全部内容

相关教程
猜你喜欢
用户评论