前面说了lru链表，为了防止mysql的预读和全表查询刷新pool的频率太高，所以把lru链表分为young区域和old区域，但是频繁的移动lru链表也影响性能，所以当在young后半部1/4区域的时候，才会移动到最前面。初始数据从磁盘刷新到内存中，先是进入old区域，当超过1S之后继续访问，则会移动到young区域。预读分为两种，第一种是当mysql检测到执行语句按顺序查询超过一定值，则会吧下一个区的所有页全部都预先刷新到缓存页里，第二种就是13个页在同一个区，这时候会吧这个区的数据全部刷新到缓存页。

LRU链表管理(2)—Buffer Pool（五十五)

刷新脏页到磁盘

前面说了每隔一段时间，会把修改了缓存页的脏数据，刷新到磁盘上，主要有两个刷新路径：

1. 从冷数据刷新一部分到磁盘(BUF_FLUSH_LRU)：后台线程会定时从lru链表尾部扫描一些页面，如果发现脏数据，则会刷新到磁盘。
2. 从flush链表中刷新一部分到磁盘(BUF_FLUSH_LIST)：刷新的速率取决于系统是不是很繁忙。

有时候刷新脏数据到磁盘比较慢，如果在没刷新之前，有新的查询过来，而free链表已经没有空闲缓存页，这时候需要去尾部吧数据释放，如果尾部存在脏数据，这时候则会强行吧脏数据持久化到磁盘上。这种方式称为BUF_FLUSH_SINGLE_PAGE。

当然有时候系统特别忙的时候，用户大量访问时，也会出现用户线程批量从flush链表持久化脏数据，磁盘的I/O操作慢的要死，显然这是迫不得已的行为，后面redo日志的checkpoint时说。

多个buffer pool实例

上面说过，mysql服务器启动的时候，就会根系统申请buffer pool的内存空间，在多线程的情况下，各个链表都需要加锁进行处理，但在buffer pool特别大，并且多线程访问量也别高的情况下，单一的buffer pool会影响处理速度。所以会吧buffer pool会分成各种小的buffer pool，这些称为实例，他们都是独立去申请内存空间，独立管理的链表，并且在多线程访问的情况下互不影响，可以通过innodb_buffer_pool_instance的值来修改buffer pool可以创建几个实例。

innodb_buffer_pool_instances = 2

表示我们需要两个buffer_pool实例。

那么每个pool_instance占多少内存呢，其实就是我们之前的总数除一下

Innodb_buffer_pool_size / innodb_buffer_pool_instances

但因为创建多个实例管理他们也是有开销的，mysql规定，当innoDB_buffer_pool_size在1G以下的时候，默认都是一个实例，设置多个也是无效的，所以只有大于1G的时候才鼓励设置多个实例。

Innodb_buffer_pool_chunk_size

在mysql5.7.5之前，buffer pool只有在mysql服务器启动之前修改，在5.7.5之后，服务器运行的时候也可以修改，但有个问题，每次当我们重新调整buffer pool的值时候 ，都要重新向系统申请一块连续的内存空间，然后再将旧的数据拷贝到新的内存中(有木有类似java的数组)，很显然这是极其耗时的。

一个buffer_pool_instance有两个chunk，因为有了这个概念，我们在服务器运行的时候，都是以chunk来增加或者删除，而不需要申请一大片空间，然后拷贝数据。

Chunk的值可以在服务器启动之前通过innodb_buffer_pool_chunk_Size来设置，默认值是134217728，也就是128，需要注意的是，这个chunk_Size只可以在服务器启动前指定。

(注意：为什么在服务器运行的时候不可以修改innodb_buffer_pool_chunk_size呢？还不是因为如果改了，前面数据存储的大小和新的就不一样，这样还是得把前面的数据copy到新的chunk，这样设置chunk的意义就不存在。)

配置buffer pool时的注意事项

innoDB_buffer_pool_size 必须是 innoDB buffer_pool_insatances * innoDB buffer_pool_chunk_size的倍数，这里主要想保证每个chunk是相等的，而且不会浪费内存空间，产生碎片。

mysqld --innodb-buffer-pool-size=8G --innodb-buffer-pool-instances=16

当我们吧pool_size改成8g，instances为16，因为chunk_size默认是128m，8G符合的倍数。

mysql> show variables like 'innodb_buffer_pool_size'
+-------------------------+------------+
| Variable_name           | Value      |
+-------------------------+------------+
| innodb_buffer_pool_size | 8589934592 |
+-------------------------+------------+
1 row in set (0.00 sec)

查看之后我们可以看到是正常的，但如果设置成9g，则会系统默认会改为10G

mysqld --innodb-buffer-pool-size=9G --innodb-buffer-pool-instances=1
mysql> show variables like 'innodb_buffer_pool_size';
+-------------------------+-------------+
| Variable_name           | Value       |
+-------------------------+-------------+
| innodb_buffer_pool_size | 10737418240 |
+-------------------------+-------------+
1 row in set (0.01 sec)

如果服务器在启动的时候，innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances 大于innoDB_buffer_pool_size，这时候，chunk_size的值会默认改为 innodb_buffer_pool_chunk_size / innodb_buffer_pool_instances。

mysqld --innodb-buffer-pool-size=2G --innodb-buffer-pool-instances=16 --innodb-buffer-pool-chunk-size=256M

因为256m*16 = 4G >2g

mysql> show variables like 'innodb_buffer_pool_size';
+-------------------------+------------
| Variable_name           | Value      |
+------------------------+------------+
| innodb_buffer_pool_size | 2147483648 |
+-------------------------+------------+
1 row in set (0.01 sec)


mysql> show variables like 'innodb_buffer_pool_chunk_size';
+-------------------------------+-----------+
| Variable_name                 | Value     |
+-------------------------------+-----------
| innodb_buffer_pool_chunk_size | 134217728 |
+------------------------------+-----------
1 row in set (0.00 

Buffer pool中存储的其他信息

Buffer pool除了存储缓存页外，还会存储锁信息，自适应哈希索引等信息，后面会详细介绍。

查看buffer pool的状态信息

mysql> SHOW ENGINE INNODB STATUS\G

(...省略前边的许多状态)
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 13218349056;
Dictionary memory allocated 4014231
Buffer pool size   786432
Free buffers       8174
Database pages     710576
Old database pages 262143
Modified db pages  124941
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 6195930012, not young 78247510485
108.18 youngs/s, 226.15 non-youngs/s
Pages read 2748866728, created 29217873, written 4845680877
160.77 reads/s, 3.80 creates/s, 190.16 writes/s
Buffer pool hit rate 956 / 1000, young-making rate 30 / 1000 not 605 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 710576, unzip_LRU len: 118
I/O sum[134264]:cur[144], unzip sum[16]:cur[0]
--------------
(...省略后边的许多状态)

mysql>

total memory allocated :表示buffer pool向操作系统申请内存，包括控制块，缓存页，碎片。

dictionary memory allocated：为数据字典分配的内存空间，这个和内存空间buffer pool没啥关系，不包含在total memory allocated。

buffer pool size：页为单位，单表buffer pool 多少缓存页。

free buffers：代表free 链表多少个节点，多少空闲缓存页。

database pages：代表lru链表多少个页数量，包含young区域和old区域。

old database pages：代表lru的old区域页数量。

modified db pages：代表脏页数量，flush链表页的数量。

pending reads：正在等待从磁盘加载到buffer pool的页面数。

当查询开始，准备从磁盘加载某个数据，会先为buffer pool分配一个缓存页和控制块，然后把这个控制块添加到old的头部，但这时候真正的磁盘页没有加载进来，pending reads+1。

pending write LRU：即将从LRU链表刷新到磁盘的页面数。

pending write flush list：从flush 链表刷新到磁盘的页面数。

pendig write single page：即将以单个页面的形式刷新到磁盘的页面数。

pages made young：代表曾从old节点数移动到young区域的数量。

只有在old节点数量移动到young里才+1，如果在young后面的1/4出移动到young区域头部，并不会+1。

page made not young：当innoDb_old_block_time的时间设置1s，但初次访问的时间和最后访问的时间没超过这个时间，导致当前数据没有移动到young里，就会让当前参数+1。

youngs/s：每秒从old区域移动到young区域的节点数。

non youngs/s：代表每秒不满足从old移动到young区域的节点数。

pages read，created，written：代表读取，创建写入多少页，后面跟着写入的速率。

buffer pool hit rate：在过去时间段，平均访问1000次页面，有多少次页面已经被缓存在buffer pool。

young-making rate：再过去时间段，平均访问1000次页面，有多少次没有使页面移动到young区域头部。

这里统计的不光从old区域移动到young区域头部，也统计从young后半部1/4区域移动到young区域头部的数据。

LRU len：代表lru链中的节点数。

unzip_lru：代表unzip_lru的节点数。

I/O sum：最近50s读取页的总数。

I/O cur：最近正在读取的磁盘数量。

I/o unzip sum：最近50s解压数量。

I/O unzip cur：正在解压页面数量。