在上一篇文章《InnoDB存储结构》中，可以从InnoDB的体系结构中看到InnoDB存储引擎主要包含两部分内容，其中表空间结构这些在该文章已经介绍了，而这篇文章将会重点介绍Buffer Pool。
一、简介
InnoDB存储引擎在处理客户端的请求时，当需要访问某个页的数据时，就会把完整的页的数据全部加载到内存中，也就是说即使我们只需要访问一个页的一条记录，那也需要先把整个页的数据加载到内存中。将整个页加载到内存中后就可以进行读写访问了，在进行完读写访问之后并不着急把该页对应的内存空间释放掉，而是将其缓存起来，这样将来有请求再次访问该页面时，就可以省去磁盘IO的开销了。
InnoDB为了缓存磁盘中的页，在MySQL服务器启动的时候就向操作系统申请了一片连续的内存，称为Buffer Pool。默认情况下Buffer Pool只有128M大小。
可以通过下面的命令查看缓冲池的大小：
show variables like 'innodb_buffer_pool_size';
可以在启动服务器的时候配置innodb_buffer_pool_size参数的值，它表示Buffer Pool的大小:
[server]
innodb_buffer_pool_size = 268435456
注：Buffer Pool也不能太小，最小值为5M(当小于该值时会自动设置成5M)。
Buffer Pool的默认值其实是偏小的，官方的给的参考是在专用数据库服务器上，可以将缓冲池大小设置为机器物理内存大小的 80%，但InnoDB 为缓冲区和控制结构保留了额外的内存，因此分配的总空间比指定的缓冲池大小大约大10%，也就是说其实按照官方的分配最终Buffer Pool占据的空间可能达到机器物理内存的90%。但即使是专用数据库服务器，还需要考虑：
- 每个查询至少需要几K的内存(有时候是几M)
- 有各种其它内部的MySQL结构和缓存
- InnoDB有一些结构是不用缓冲池的内存的(字典缓存，文件系统等)
- 部门MySQL文件是在OS缓存里的(binary日志，relay日志,innodb事务日志等)
- 为操作系统留出些内存
比较权衡的值是70%~75%之间，但是需要监控好服务器的内存使用情况。通过下面的命令可以看到缓冲池的命中率：
show engine innodb status;
注：在专用数据库服务器中，BufferPool通常可以设置为物理内存的60%，这是比较稳妥的。
二、Buffer Pool内部组成
2.1 控制块+缓存页
Buffer Pool中默认的缓存页大小和在磁盘上默认的页大小是一样的，都是16KB。为了更好的管理这些在Buffer Pool中的缓存页，InnoDB为每一个缓存页都创建了一些所谓的控制信息，这些控制信息包括该页所属的表空间编号、页号、缓存页在Buffer Pool中的地址、链表节点信息、一些锁信息以及LSN信息，当然还有一些别的控制信息。
每个缓存页对应的控制信息占用的内存大小是相同的，称为控制块。控制块和缓存页是一一对应的，它们都被存放到Buffer Pool 中，其中控制块被存放到Buffer Pool的前边，缓存页被存放到Buffer Pool后边，所以整个Buffer Pool对应的内存空间看起来就是这样的：
注：每个控制块大约占用缓存页大小的5%，而设置的innodb_buffer_pool_size并不包含这部分控制块占用的内存空间大小，也就是说InnoDB在为Buffer Pool向操作系统申请连续的内存空间时，这片连续的内存空间一般会比innodb_buffer_pool_size的值大5%左右。
2.2 Free链表管理
MySQL服务在刚启动的时候，需要完成对Buffer Pool的初始化，也就是向操作系统申请Buffer Pool的存储空间，然后它们划分为若干对控制块和缓存页。
但此时还没有使用，所以Buffer Pool中还没有真实的页数据，随着程序运行，就会慢慢有磁盘页数据被缓存在Buffer Pool中。
对于InnoDB来说，将磁盘页读取到Buffer Pool中有几个关键问题，即哪些缓存页是空闲，哪些缓存页已经被使用了。
缓存页对应的控制块就起了大作用，可以把所有空闲的缓存页对应的控制块作为一个节点放到一个链表中，这个链表也可以被称作free链表，或者说空闲链表。
刚完成初始化的Buffer Pool中所有的缓存页都是空闲的，所以每一个缓存页对应的控制块都会被加入到free链表中，free链表的效果图就是这样的：
有了这个free链表之后，每当需要从磁盘中加载一个页到Buffer Pool中时，就从free链表中取一个空闲的缓存页，并且把该缓存页对应的控制块的信息填上(就是该页所在的表空间、页号之类的信息)，然后把该缓存页对应的free链表节点从链表中移除，表示该缓存页已经被使用了。
2.3 缓存页的哈希处理
当访问某个页的数据时，如何知道该页已经在Buffer Pool中了呢？
InnoDB根据表空间号 + 页号来定位一个页，所以可以用表空间号 + 页号作为key，缓存页作为value创建一个哈希表，在需要访问某个页的数据时，先从哈希表中根据表空间号 + 页号看看有没有对应的缓存页，如果有，直接使用该缓存页就好，如果没有，那就从free链表中选一个空闲的缓存页，然后把磁盘中对应的页加载到该缓存页的位置。
2.4 flush链表管理
如果修改了Buffer Pool中某个缓存页的数据，那它就和磁盘上的页不一致了，这样的缓存页也被称为脏页(Dirty Page)。
内存的数据修改后，要保证磁盘上的数据也同步进行修改，最简单的做法就是每发生一次修改就立即同步到磁盘上对应的页上，但是频繁的往磁盘中写数据会严重的影响程序的性能。所以每次修改缓存页后，我们并不着急立即把修改同步到磁盘上，而是在未来的某个时间点进行同步。
在同步内存数据到磁盘中时，需要知道Buffer Pool中哪些缓存页的数据发生了变化，所以同样需要一个存储脏页的链表，凡是修改过的缓存页对应的控制块都会作为一个节点加入到一个链表中，因为这个链表节点对应的缓存页都是需要被刷新到磁盘上的，所以也叫flush链表。链表的构造和free链表差不多。
2.5 LRU链表管理
Buffer Pool的大小是有限的，free链表总归有用完的时候，这个时候就涉及到缓存页淘汰的问题了，把旧的缓存页移除，然后把新的缓存页放进来。
Buffer Pool的初衷就是为了减少磁盘IO的次数，缓存命中率越高越好。
所以，Buffer Pool的淘汰策略使用LRU算法,淘汰最近最少使用的缓存页，留下最近使用比较频繁的缓存页。
InnoDB为了知道哪些缓存页是最近使用的，就需要再创建一个链表，该链表使用LRU算法来淘汰缓存页，所以称为LRU链表，当访问某个页时，它的工作过程如下：
- 如果该页不在
Buffer Pool中，就把该页从磁盘加载到Buffer Pool中的缓存页时，然后把该缓存页对应的控制块作为节点塞到LRU链表的头部 - 如果该页已经缓存在Buffer Pool中，则直接把该页对应的控制块移动到LRU链表的头部。
只要我们使用到某个缓存页，就把该缓存页调整到LRU链表的头部，这样LRU链表尾部就是最近最少使用的缓存页。所以当Buffer Pool中的空闲缓存页使用完时，到LRU链表的尾部找些缓存页淘汰就可以了。
这种简单的LRU链表其实是有一些问题，主要与InnoDB自生的一些特性和SQL语句有关：
2.5.1 预读
InnoDB提供了预读(read ahead)。所谓预读，就是InnoDB认为执行当前的请求可能之后会读取某些页面，就预先把它们加载到Buffer Pool中。根据触发方式的不同，预读又可以细分为下边两种：
-
线性预读
InnoDB提供了一个系统变量
innodb_read_ahead_threshold，如果顺序访问了某个区(extent)的页面超过这个系统变量的值，就会触发一次异步读取下一个区中全部的页面到Buffer Pool的请求。
这个innodb_read_ahead_threshold系统变量的值默认是56，我们可以在服务器启动时通过启动参数或者服务器运行过程中直接调整该系统变量的值，取值范围是0~64。 -
随机预读
如果Buffer Pool中已经缓存了某个区的13个连续的页面，不论这些页面是不是顺序读取的，都会触发一次异步读取本区中所有其他的页面到Buffer Pool的请求。InnoDB同时提供了
innodb_random_read_ahead系统变量，它的默认值为OFF。可以通过下面的命令查看：
show variables like '%_read_ahead%';
如果预读到Buffer Pool中的页成功的被使用到，那就可以极大的提高语句执行的效率。如果用不到，这些预读的页都会放到LRU链表的头部，但是如果此时Buffer Pool的容量不太大而且很多预读的页面都没有用到的话，这就会导致处在LRU链表尾部的一些缓存页会很快的被淘汰掉，也就是所谓的劣币驱逐良币，会大大降低缓存命中率。
总结这两种情况就是：
加载到Buffer Pool中的页不一定被用到，如果非常多的使用频率偏低的页被同时加载到Buffer Pool时，可能会把那些使用频率非常高的页从Buffer Pool中淘汰掉。
因为有这两种情况的存在，所以InnoDB把这个LRU链表按照一定比例分成两截，分别是：
1、一部分存储使用频率非常高的缓存页，所以这一部分链表也叫做热数据，或者称young区域。
2、另一部分存储使用频率不是很高的缓存页，所以这一部分链表也叫做冷数据，或者称old区域。
大概结构如下图所示：
young区和old区的分界点并不是固定的，对于InnoDB存储引擎来说，可以通过查看系统变量innodb_old_blocks_pct的值来确定old区域在LRU链表中所占的比例：
SHOW VARIABLES LIKE 'innodb_old_blocks_pct';
从结果可以看出来，默认情况下，old区域在LRU链表中所占的比例是37%，也就是说old区域大约占LRU链表的3/8。这个比例我们是可以设置的，我们可以在启动时修改innodb_old_blocks_pct参数来控制old区域在LRU链表中所占的比例。
2.5.2 全表扫描
扫描全表的查询语句(比如没有建立合适的索引或者压根儿没有WHERE子句的查询)意味着将访问该表所在的所有页！
假设这个表中记录非常多的话，那该表会占用特别多的页，当需要访问这些页时，会把它们统统都加载到Buffer Pool中，这也就意味着Buffer Pool中的所有页都被换了一次血，其他查询语句在执行时又得执行一次从磁盘加载到Buffer Pool的操作。而这种全表扫描的语句执行的频率也不高，每次执行都要把Buffer Pool中的缓存页换一次血，这严重的影响到其他查询对Buffer Pool的使用，从而大大降低了缓存命中率。
如果非常多的使用频率偏低的页被同时加载到Buffer Pool时，可能会把那些使用频率非常高的页从Buffer Pool中淘汰掉。
对于这两种情况，InnoDB规定，当磁盘上的某个页面在初次加载到Buffer Pool中的某个缓存页时，该缓存页对应的控制块会被放到old区域的头部。这样针对预读到Buffer Pool却不进行后续访问的页面就会被逐渐从old区域逐出，而不会影响young区域中被使用比较频繁的缓存页。
在进行全表扫描时，虽然首次被加载到Buffer Pool的页被放到了old区域的头部，但是后续会被马上访问到，每次进行访问的时候又会把该页放到young区域的头部，这样仍然会把那些使用频率比较高的页面给顶下去。
但全表扫描有一个特点，那就是它的执行频率非常低，出现了全表扫描的语句也是我们应该尽快优化的对象。而且在执行全表扫描的过程中，即使某个页面中有很多条记录需要访问，也就是去多次访问这个页面所花费的时间也是非常少的。
所以在对某个处在old区域的缓存页进行第一次访问时就在它对应的控制块中记录下来这个访问时间，如果后续的访问时间与第一次访问的时间在某个时间间隔内，那么该页面就不会被从old区域移动到young区域的头部，否则将它移动到young区域的头部。上述的这个间隔时间是由系统变量innodb_old_blocks_time控制的：
SHOW VARIABLES LIKE 'innodb_old_blocks_time';
这个innodb_old_blocks_time的默认值是1000，它的单位是毫秒，也就意味着对于从磁盘上被加载到LRU链表的old区域的某个页来说，如果第一次和最后一次访问该页面的时间间隔小于1s（很明显在一次全表扫描的过程中，多次访问一个页面中的时间不会超过1s），那么该页是不会被加入到young区域的， 当然，像innodb_old_blocks_pct一样，我们也可以在服务器启动或运行时设置innodb_old_blocks_time的值，这里需要注意的是，如果我们把innodb_old_blocks_time的值设置为0，那么每次我们访问一个页面时就会把该页面放到young区域的头部。
三、脏页刷新
InnoDB有专门的后台线程每隔一段时间负责把脏页刷新到磁盘，这样可以不影响用户线程处理正常的请求。主要有两种刷新路径：
-
从LRU链表的冷数据中刷新一部分页面到磁盘
后台线程会定时从LRU链表尾部开始扫描一些页面，扫描的页面数量可以通过系统变量
innodb_lru_scan_depth来指定，如果从里边儿发现脏页，会把它们刷新到磁盘。这种刷新页面的方式被称之为BUF_FLUSH_LRU。 -
从flush链表中刷新一部分页面到磁盘
后台线程也会定时从flush链表中刷新一部分页面到磁盘，刷新的速率取决于当时系统是不是很繁忙。这种刷新页面的方式被称之为BUF_FLUSH_LIST。
有时候后台线程刷新脏页的进度比较慢，导致用户线程在准备加载一个磁盘页到
Buffer Pool时没有可用的缓存页，这时就会尝试看看LRU链表尾部有没有可以直接释放掉的未修改页面，如果没有的话会不得不将LRU链表尾部的一个脏页同步刷新到磁盘（和磁盘交互是很慢的，这会降低处理用户请求的速度）。这种刷新单个页面到磁盘中的刷新方式被称之为BUF_FLUSH_SINGLE_PAGE。
四、多个Buffer Pool实例
Buffer Pool本质是InnoDB向操作系统申请的一块连续的内存空间，在多线程环境下，访问Buffer Pool中的各种链表都需要加锁处理，在Buffer Pool特别大而且多线程并发访问特别高的情况下，单一的Buffer Pool可能会影响请求的处理速度。
所以在Buffer Pool特别大的时候，我们可以把它们拆分成若干个小的Buffer Pool，每个Buffer Pool都称为一个实例，它们都是独立的，独立的去申请内存空间，独立的管理各种链表，所以在多线程并发访问时并不会相互影响，从而提高并发处理能力。
可以在服务器启动的时候通过设置innodb_buffer_pool_instances的值来修改Buffer Pool实例的个数。
每个Buffer Pool实例实际占内存空间 = innodb_buffer_pool_size / innodb_buffer_pool_instances
也不是说Buffer Pool实例创建的越多越好，分别管理各个Buffer Pool也是需要性能开销的，InnoDB规定：innodb_buffer_pool_instances能设置的最大值是64，而且当innodb_buffer_pool_size（默认128M）的值小于1G的时候设置多个实例是无效的，InnoDB会默认把innodb_buffer_pool_instances的值修改为1。
按照官方的说明，最佳的innodb_buffer_pool_instances的数量是，innodb_buffer_pool_size除以innodb_buffer_pool_instances，可以让每个Buffer Pool实例达到1个G，这个公式在8.0和5.7中都适用。
五、动态修改Buffer Pool大小
在MySQL 5.7.5之前，Buffer Pool的大小只能在服务器启动时通过配置innodb_buffer_pool_size启动参数来调整大小，在服务器运行过程中是不允许调整该值的。不过MySQL在5.7.5以及之后的版本中支持了在服务器运行过程中调整Buffer Pool大小的功能。
但是有一个问题，就是每次当我们要重新调整Buffer Pool大小时，都需要重新向操作系统申请一块连续的内存空间，然后将旧的Buffer Pool中的内容复制到这一块新空间，这是极其耗时的。
所以MySQL决定不再一次性为某个Buffer Pool实例向操作系统申请一大片连续的内存空间，而是以一个所谓的chunk为单位向操作系统申请空间。
也就是说一个Buffer Pool实例其实是由若干个chunk组成的，一个chunk就代表一片连续的内存空间，里边儿包含了若干缓存页与其对应的控制块：
正是有了chunk的概念，在服务器运行期间调整Buffer Pool的大小时就是以chunk为单位增加或者删除内存空间，而不需要重新向操作系统申请一片大的内存，然后进行缓存页的复制。
这个所谓的chunk的大小是我们在启动操作MySQL服务器时通过innodb_buffer_pool_chunk_size启动参数指定的，它的默认值是134217728，也就是128M。不过需要注意的是，innodb_buffer_pool_chunk_size的值只能在服务器启动时指定，在服务器运行过程中是不可以修改的。
Buffer Pool的缓存页除了用来缓存磁盘上的页面以外，还可以存储锁信息、自适应哈希索引等信息。