前面说了lru链表，为了防止mysql的预读和全表查询刷新pool的频率太高，所以把lru链表分为young区域和old区域，但是频繁的移动lru链表也影响性能，所以当在young后半部1/4区域的时候，才会移动到最前面。初始数据从磁盘刷新到内存中，先是进入old区域，当超过1S之后继续访问，则会移动到young区域。预读分为两种，第一种是当mysql检测到执行语句按顺序查询超过一定值，则会吧下一个区的所有页全部都预先刷新到缓存页里，第二种就是13个页在同一个区，这时候会吧这个区的数据全部刷新到缓存页。
刷新脏页到磁盘
前面说了每隔一段时间，会把修改了缓存页的脏数据，刷新到磁盘上，主要有两个刷新路径：
从冷数据刷新一部分到磁盘(BUF_FLUSH_LRU)：后台线程会定时从lru链表尾部扫描一些页面，如果发现脏数据，则会刷新到磁盘。
从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符合的倍数。
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)
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
如果服务器在启动的时候，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：正在解压页面数量。
