对于InnoDB存储引擎，不管用户数据还是系统数据都是以页的形式存储在表空间进行管理的，其实都是存储在磁盘上的。
当InnoDB处理客户端请求，需要读取某页的一条记录时，就会将这个页中的所有数据加载到内存中，再进行读写操作，当读写操作完成后，不是先将内存空间释放，而是将其缓存起来，当下次有同样的请求时，可以省去磁盘IO的开销。
而InnoDB缓存这些页的内存就叫做Buffer Pool，（5.7.5v之前这是一块连续的内存，可以在配置文件中以innodb_buffer_pool_size动态修改其大小，这之后，以chunk为单位想操作系统申请空间，Buffer Pool由若干个chunk组成，一个chunk就是一片连续的空间）如果Buffer Pool大小大于1G时，那么可以被拆分成若干个小的独立的实例（系统变量innodb_buffer_pool_instances设置个数），缓存页的映射是有特定算法的，所以不存在重复缓存页，且在多线程访问时，互不影响。
（TODO Buffer Pool配置注意事项+Buffer Pool的状态信息查看SHOW ENGINE INNODB STATUS）
Buffer Pool由n个控制块和n个缓存页还有一些碎片组成，控制块与缓存页一一对应。
缓存页：和磁盘上的页一样都是16kb大小，存放在Buffer Pool后边
控制块：存放了一些控制信息包含页所属的表空间编号/页号/缓存页在Buffer Pool中的位置/链表节点信息/锁信息/LSN信息等，存放在Buffer Pool前边，大小约为缓存页的5%
碎片：Buffer Pool中不能再分配的空间
Buffer Pool在MySQL服务器启动时，就会完成初始化工作：申请Buffer Pool内存空间，划分若干对控制块和缓存页；其中缓存页的的使用情况会用到一些数据格式来管理，如空闲缓存页，被修改过的脏页等用到双向链表。
free链表记录Buffer Pool中哪些缓存页是可用的，将缓存页对应的控制块作为一个节点存放在链表中，在Buffer Pool初始化时，是将所有控制块都存放的。free链表定义了一个基节点，存储了链表的头尾节点；每当需要使用一个缓存页时，都会从free链表取出一个空闲的缓存页，将控制信息填上，并将对应的缓存页节点从free链表移除。
申明一个hash表，以表空间号+页号为key，缓存页为value存储已经被加载到缓存中的缓存页，这样就可以很快定位哪些页已经被缓存了，就无需重复为这个页申请缓存页
脏页是修改了已经被加载到Buffer Pool中的缓存页数据，导致它和磁盘上的不一致。为了将这些脏页都同步到磁盘上，创建了一个flush链表，用于存储这些脏页的信息，隔一段时间就将这些数据同步到磁盘。flush链表和free链表构造一样
刷新脏页到磁盘，有两种方式（在flush链表的页肯定也在LRU链表）
Buffer Pool的大小是有限的，所以需要将一些旧的缓存页从Buffer Pool中移除，但是移除缓存页时也期望缓存集中率高
为了考虑两种可能会导致缓存命中率降低情况，所以需要对这个链表做一定的设计
预读read ahead
- 线性预读（使用操作系统核心提供的AIO接口异步读取下一个区中全部的页面到Buffer Pool）
- 随机预读（如果
Buffer Pool中已经缓存了某个区的13个连续（即young区域的头1/4）的页面，不论这些页面是不是顺序读取的，都会触发一次异步读取本区中所有其的页面到Buffer Pool的请求）
这个预读到的页如果真的被访问到，是可以提高效率的，但如果没有被访问，就会浪费内存，且让存放在链表尾部的缓存被淘汰，降低了缓存命中率；
LRU链表以按照最近最少使用的原则去淘汰缓存页，将这个链表分为两截（young区和old区，以使用频率高低区分，系统变量innodb_old_blocks_pct确定old区所占比例）
当访问某个页不存在缓存页中时（初始读），将这个缓存页的控制块放到old区，并在对应的控制块中记录下访问时间，这样预读/全表扫描的不被后续访问的页面就会逐渐从old区移除，如果后续被访问时，比较当前访问时间和记录的时间是否在一个时间间隔内（系统变量innodb_old_blocks_time查看），如果不在就会把页放到young区域的头部，反之，不会移动；这样就会减少将young中使用频率较高的页给顶下去的机会。
但是频繁的移动也会产生比较大的开销，所以规定只要被访问的缓存页位于young区域的1/4的后面，才会被移动到LRU链表的头部，降低调整LRU链表的频率
原文：https://www.cnblogs.com/hangzhi/p/11279541.html