在5.7里有个问题值得关注，即buffer pool size会根据instances * chunk size向上对齐，举个简单的例子，假设你配置了64个instance, chunk size为默认128MB，就需要以8GB进行对齐，这意味着如果你配置了9GB的buffer pool，实际使用的会是16GB。所以尽量不要配置太多的buffer pool instance。
buffer pool 链表及管理对象出于不同的目的，每个buffer pool instance上都维持了多个链表，可以根据space id及page no找到对应的instance(buf_pool_get)。
一些关键的结构对象及描述如下表所示：
namedescbuf_pool_t::page_hash page_hash用于存储已经或正在读入内存的page。根据<space_id, page_no>快速查找。当不在page hash时，才会去尝试从文件读取
buf_pool_t::LRU LRU上维持了所有从磁盘读入的数据页，该LRU上又在链表尾部开始大约3/8处将链表划分为两部分，新读入的page被加入到这个位置；当我们设置了innodb_old_blocks_time，若两次访问page的时间超过该阀值，则将其挪动到LRU头部；这就避免了类似一次性的全表扫描操作导致buffer pool污染
buf_pool_t::free 存储了当前空闲可分配的block
buf_pool_t::flush_list 存储了被修改过的page，根据oldest_modification（即载入内存后第一次修改该page时的Redo LSN）排序
buf_pool_t::flush_rbt 在崩溃恢复阶段在flush list上建立的红黑数，用于将apply redo后的page快速的插入到flush list上，以保证其有序
buf_pool_t::unzip_LRU 压缩表上解压后的page被存储到unzip_LRU。 buf_block_t::frame存储解压后的数据，buf_block_t::page->zip.data指向原始压缩数据。
buf_pool_t::zip_free[BUF_BUDDY_SIZES_MAX] 用于管理压缩页产生的空闲碎片page。压缩页占用的内存采用buddy allocator算法进行分配。
buffer pool 并发控制
除了不同的用户线程会并发操作buffer pool外，还有后台线程也会对buffer pool进行操作。InnoDB通过读写锁、buf fix计数、io fix标记来进行并发控制。
读写并发控制
通常当我们读取到一个page时，会对其加block S锁，并递增buf_page_t::buf_fix_count，直到mtr commit时才会恢复。而如果读page的目的是为了进行修改，则会加X锁。
当一个page准备flush到磁盘时(buf_flush_page)，如果当前Page正在被访问，其buf_fix_count不为0时，就忽略flush该page，以减少获取block上SX Lock的昂贵代价。
并发读控制
当多个线程请求相同的page时，如果page不在内存，是否可能引发对同一个page的文件IO ？答案是不会。
从函数buf_page_init_for_read我们可以看到，在准备读入一个page前，会做如下工作：
分配一个空闲block；
buf_pool_mutex_enter；
持有page_hash x lock；
检查page_hash中是否已被读入，如果是，表示另外一个线程已经完成了io，则忽略本次io请求，退出；
持有block->mutex，对block进行初始化，并加入到page hash中；
设置IO FIX为BUF_IO_READ；
释放hash lock；
将block加入到LRU上；
持有block s lock；
完成IO后，释放s lock；
当另外一个线程也想请求相同page时，首先如果看到page hash中已经有对应的block了，说明page已经或正在被读入buffer pool，如果io_fix为BUF_IO_READ，说明正在进行IO，就通过加X锁的方式做一次sync（buf_wait_for_read），确保IO完成。
请求Page通常还需要加S或X锁，而IO期间也是持有block x锁的，如果成功获取了锁，说明IO肯定完成了。
Page驱逐及刷脏当buffer pool中的free list不足时，为了获取一个空闲block，通常会触发page驱逐操作(buf_LRU_free_from_unzip_LRU_list)。
首先由于压缩页在内存中可能存在两份拷贝：压缩页和解压页；InnoDB根据最近的IO情况和数据解压技术来判定实例是处于IO-BOUND还是CPU-BOUND（buf_LRU_evict_from_unzip_LRU）。如果是IO-BOUND的话，就尝试从unzip_lru上释放一个block出来(buf_LRU_free_from_unzip_LRU_list)，而压缩页依旧保存在内存中。
其次再考虑从buf_pool_t::LRU链表上释放block，如果有可替换的page(buf_flush_ready_for_replace)时，则将其释放掉，并加入到free list上；对于压缩表，压缩页和解压页在这里都会被同时驱逐。