缓存管理是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 possible write hole
](https://bugs.mysql.com/bug.php?id=94912))）
再一个重要功能是终于引入了multiple page cleaner, 可以多个后台线程并发刷脏页，提供了更好的刷脏性能，有效避免用户线程进入single page flush。当然这还不够完美，主要有四点：
- 用户线程依然会进入single page flush，而一旦大量线程进入，就会导致严重性能下降：超频繁的fsync，激烈的dblwr竞争，线程切换等等
- 当redo空间不足时，用户线程也会进入page flush，这在高负载场景下是很常见的，你会发现系统运行一段时间后，性能急剧下降。这是因为redo产生太快，而page flush又跟不上，导致checkpoint无法推进。那么用户线程可能就要过来做fuzzy checkpoint了。那时候性能基本上没法看了。
- dblwr成为重要的单点瓶颈。 如果你的服务器不支持原子写的话，必须打开double write buffer。写入Ibdata一段固定区域，这里是有锁包含的，区分为两部分：single page flush和batch flush, 但无论如何，即使拆分了多个page cleaner，最终扩展性还是受限于dblwr
- 没有专用的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:
- LRU_list_mutex for the LRU_list;
- zip_free mutex for the zip_free arrays;
- zip_hash mutex for the zip_hash hash and in_zip_hash flag;
- free_list_mutex for the free_list and withdraw list.
- 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的瓶颈问题，期待一下.
本文作者：zhaiwx_yinfeng
阅读原文
本文为云栖社区原创内容，未经允许不得转载。