缓存管理是DBMS的核心系统，用于管理数据页的访问、刷脏和驱逐；虽然操作系统本身有page cache，但那不是专门为数据库设计的，所以大多数数据库系统都是自己来管理缓存。由于几乎所有的数据页访问都涉及到Buffer Pool，因此buffer pool的并发访问控制尤为重要，可能会影响到吞吐量和响应时间，本文主要回顾一下MySQL的buffer Pool最近几个版本的发展(若有遗漏，欢迎评论补充), 感受下最近几年这一块的进步

MySQL5.5之前

只能设置一个buffer pool, 通过innodb_buffer_pool_size来控制, 刷脏由master线程承担，扩展性差。

MySQL 5.5

引入参数innodb_buffer_pool_instances，将buffer pool拆分成多个instance，从而减少对buffer pool的访问控制，这时候的刷脏还是由Master线程来承担。

MySQL 5.6

引入了buffer Pool page Id转储和导入特性，也就是说可以随时把内存中的page no存下来到文件里，在重启时会自动把这些Page加载到内存中，使内存保持warm状态. 此外该版本第一次引入了page cleaner,将flush list/lru上的刷脏驱逐工作转移到单独线程，减少了master线程的负担

MySQL 5.7

这个版本发布了一个重要特性：online buffer pool resize. 当然是否是online需要打一个问号，因为在resize的过程中需要拿很多全局大锁，在高负载场景下很容易导致实例Hang住(81615)。 和之前不同，buffer pool被分成多个instance，每个instance又由多个chunk组成，每个chunk的大小受到参数innodb_buffer_pool_chunk_size控制，默认128MB, buffer pool resize都是以chunk为单位增加或减少的。 另外一个需要注意的点是：你配置的Buffer Pool Size可能比你实际使用的内存要大，尤其对于大Bp而言，这是因为内部做了对齐处理, buffer pool size必须以 innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances来做向上对齐(80350)

我们知道通常数据文件的IO都被设置成O_DIRECT, 但每次修改后依然需要去做fsync，来持久化元数据信息，而对于某些文件系统而言是没必要做fsync的，因此加入了新选项O_DIRECT_NO_FSYNC，这个需求来自于facebook. 他们也对此做了特殊处理：除非文件size变化，否则不做fsync。（最近在buglist上对这个参数是否安全的讨论也很有意思，官方文档做了新的说明，感兴趣的可以看看 [94912:O_DIRECT_NO_FSYNC poss

再一个重要功能是终于引入了multiple page cleaner, 可以多个后台线程并发刷脏页，提供了更好的刷脏性能，有效避免用户线程进入single page flush。当然这还不够完美，主要有四点：

  1. 用户线程依然会进入single page flush，而一旦大量线程进入，就会导致严重性能下降：超频繁的fsync，激烈的dblwr竞争，线程切换等等
  2. 当redo空间不足时，用户线程也会进入page flush，这在高负载场景下是很常见的，你会发现系统运行一段时间后，性能急剧下降。这是因为redo产生太快，而page flush又跟不上，导致checkpoint无法推进。那么用户线程可能就要过来做fuzzy checkpoint了。那时候性能基本上没法看了。
  3. dblwr成为重要的单点瓶颈。 如果你的服务器不支持原子写的话，必须打开double write buffer。写入Ibdata一段固定区域，这里是有锁包含的，区分为两部分：single page flush和batch flush, 但无论如何，即使拆分了多个page cleaner，最终扩展性还是受限于dblwr
  4. 没有专用的lru evict线程，都是Page cleaner键值的。举个简单的例子，当buffer pool占满，同时又有很多脏页时，Page cleaner可能忙于刷脏，而用户线程则得不到free page，从而陷入single page flush

如果你对上述几个问题极不满意，可以尝试percona server, 他们向来擅长优化Io bound场景的性能，并且上述几个问题都解决了，尤其是dblwr，他们做了多分区的改进。

MySQL 8.0

增加了一个功能，可以在实例宕机时，core文件里不去掉buffer pool, 这大大减少了core文件的大小。要知道，很多时候实例挂是因为文件损坏，不停的core重启会很快把磁盘占满，你可以通过设置参数innodb_buffer_pool_in_core_file来控制。

另外8.0最重要的一个改进就是：终于把全局大锁buffer pool mutex拆分了，各个链表由其专用的mutex保护，大大提升了访问扩展性。实际上这是由percona贡献给上游的，而percona在5.5版本就实现了这个特性(WL#8423: InnoDB: Remove the buffer pool mutex 以及 bug#75534)。

原来的一个大mutex被拆分成多个为free_list, LRU_list, zip_free, 和zip_hash单独使用mutex:

  1.   - LRU_list_mutex for the LRU_list;
  2.   - zip_free mutex for the zip_free arrays;
  3.   - zip_hash mutex for the zip_hash hash and in_zip_hash flag;
  4.   - free_list_mutex for the free_list and withdraw list.
  5.   - flush_state_mutex for init_flush, n_flush, no_flush arrays.

由于log system采用lock-free的方式重新实现，flush_order_mutex也被移除了，带来的后果是flush list上部分page可能不是有序的，进而导致checkpoint lsn和以前不同，不再是某个log record的边界，而是可能在某个日志的中间，给崩溃恢复带来了一定的复杂度（需要回溯日志）

log_free_check也发生了变化，当超出同步点时，用户线程不再自己去做preflush，而是通知后台线程去做，自己在那等待(log_request_checkpoint), log_checkpointer线程会去考虑log_consider_sync_flush，这时候如果你打开了参数innodb_flush_sync的话, 那么flush操作将由page cleaner线程来完成，此时page cleaner会忽略io capacity的限制，进入激烈刷脏

8.0还增加了一个新的参数叫innodb_fsync_threshold，，例如创建文件时，会设置文件size,如果服务器有多个运行的实例，可能会对其他正常运行的实例产生明显的冲击。为了解决这个问题，从8.0.13开始，引入了这个阈值，代码里在函数os_file_set_size注入，这个函数通常在创建或truncate文件之类的操作时调用，表示每写到这么多个字节时，要fsync一次，避免对系统产生冲击。这个补丁由facebook贡献给上游。

其他 当然也有些辅助结构来快速查询buffer pool:

adaptive hash index: 直接把叶子节点上的记录索引了，在满足某些条件时，可以直接定位到叶子节点上，无需从根节点开始扫描，减少读的page个数 page hash: 每个buffer pool instance上都通过辅助的page hash来快速访问其中存储的page，读加s锁，写入新page加x锁。page hash采用分区的结构，默认为16，有一个参数innodb_page_hash_locks，但很遗憾，目前代码里是debug only的，如果你想配置这个参数，需要稍微修改下代码，把参数定义从debug宏下移出来 change buffer: 当二级索引页不在时，可以把操作缓存到ibdata里的一个btree(ibuf)中，下次需要读入这个page时，再做merge；另外后台master线程会也会尝试merge ibuf。

最后，听说官方正在努力解决double write buffer的瓶颈问题，期待一下.