为什么OS已经有了页面置换机制，MySQL中的Buffer Pool还需要再实现一遍？-526互联

问题引入

舍友最近在找实习，简历上有CMU15-445经典数据库项目。在面试时被问到：

MySQL在默认配置下，读取一行数据，要先打开磁盘中对应的数据页，这时因为局部性，会直接复制一份磁盘文件的整页数据到Page Cache中。

然后，这一页还会被读到用户空间的Buffer Pool中；Buffer Pool中数据的修改，对Page Cache没有影响。

当Buffer Pool淘汰了数据页，会把脏页的内容刷进Page Cache。之后fsync()才会把Page Cache的内容刷到磁盘中。

这里Page Cache和Buffer Pool的内容有重叠，浪费内存了。所以MySQL提供了O_DIRECT方式，可以绕过Page Cache，节省内存。

回到最初的问题，数据库文件太大，Buffer Pool只按需缓存其中一部分内容到内存。而Buffer Pool是用户内存空间的一部分，又受到OS页面置换的管理。

Buffer Pool的置换算法管理的是哪些磁盘页被调入虚拟内存；OS的置换算法管理的是Buffer Pool的虚拟内存中，哪些部分使用实际物理内存，剩余部分被swap到磁盘中。

回答第2个问题：OS的置换只是超出了实际物理内存空间才会进行，平时对Buffer Pool应当没有影响。所以Buffer Pool的大小应该合理设置，如果太大，超出的部分会经常被OS给置换，影响效率；而太小，就达不到缓存的效果了，因为要不停自我置换。

那可不可以Buffer Pool不实现磁盘页置换，把数据文件全都装进来？反正虚拟内存空间很大嘛，需要的时候OS会帮我们调。

我想这样不太好，因为Buffer Pool中应该会使用哈希表，保存数据页号到Buffer Pool中地址的映射，如果不置换，这个哈希表越来越大，查起来就很慢了。

还有个原因我觉得是，自定义的置换算法比较灵活，可以根据数据库的特性去调整，并随着版本更新去不断优化调整。而OS是通用的置换，不够灵活。

到这里还有一个想法：是否可以用O_DIRECT方式的mmap把整个数据库文件映射到内存里，这样完全由OS进行页面置换管理？我去查了下为什么没人这么干，搜到一篇回答，可以看参考资料中的最后一篇。

大意说的是mmap不够灵活，即使使用了mmap，代码量也不会减少很多。Buffer Pool实际上是mmap的重新实现。