在之前的2篇文章中,我们讲了在update过程中,为了保证数据的主从一致性、系统崩溃时的数据安全性和磁盘写入的高效性,mysql分别引入了两阶段提交和组提交的机制。这篇文章讲述bufferpool如何加速读写。
缓存的作用
把磁盘上的数据加载到缓存，避免每次访问都进行磁盘IO，起到加速访问的作用。那为啥不把所有数据都放到缓存里?
凡事都具备两面性，抛开数据易失性不说，访问快速的反面是存储容量小：
（1）缓存访问快，但容量小，数据库存储了200G数据，缓存容量可能只有64G；
（2）内存访问快，但容量小，买一台笔记本磁盘有2T，内存可能只有16G；
因此，只能把“最热”的数据放到“最近”的地方，以“最大限度”的降低磁盘访问。
缓冲池bufferpool
应用系统分层架构，为了加速数据访问，会把最常访问的数据，放在缓存(cache)里，避免每次都去访问数据库。操作系统，会有缓冲池(buffer pool)机制，避免每次访问磁盘，以加速数据的访问。
MySQL作为一个存储系统，同样具有缓冲池(buffer pool)机制，以避免每次查询数据都进行磁盘IO。
我们知道数据库中的数据实际上最终都是要存放在磁盘文件上的。但是我们在对数据库执行增删改操作的时候，不可能直接更新磁盘上的数据的，因为如果你对磁盘进行随机读写操作，那速度是相当的慢，随便一个大磁盘文件的随机读写操作，可能都要几百毫秒。如果要是那么搞的话，可能你的数据库每秒也就只能处理几百个请求了！
在对数据库执行增删改操作的时候，实际上主要都是针对内存里的Buffer Pool中的数据进行的，也就是你实际上主要是对数据库的内存里的数据结构进行了增删改，如下图所示。
但是如果在数据库的内存里执行了一堆增删改的操作，内存数据是更新了，但是这个时候如果数据库突然崩溃了，那么内存里更新好的数据不是都没了吗？
针对这个问题mysql引入了一个redo log机制，你在对内存里的数据进行增删改的时候，他同时会把增删改对应的日志写入redo log中，如下图。
万一你的数据库突然崩溃了，没关系，只要从redo log日志文件里读取出来你之前做过哪些增删改操作，瞬间就可以重新把这些增删改操作在你的内存里执行一遍，这就可以恢复出来你之前做过哪些增删改操作了。
加速读
在数据库中进行读取页的操作，首先把从磁盘读到的页存放在缓存池中，下一次读取相同的页时，首先判断该页是不是在缓存池中。如果在该页在缓存池中被命中，则直接读取该页，否则，还是去读取磁盘上的页。
Buffer Pool 一个最主要的功能是加速读。加速读是当需要访问一个数据页面的时候，如果这个页面已经在缓存池中，那么就不再需访问磁盘，直接从缓冲池中就能获取这个页面的内容。当我们需要访问某个页中的数据时，就会把该页加载到 Buffer Pool 中，如果该页已经在 Buffer Pool 中的话直接使用就可以了。
问题：那么如何快速查找在 Buffer Pool 中的页呢？
为了避免查询数据页时扫描 Lru，其实是根据表空间号 + 页号来定位一个页的，也就相当于表空间号 + 页号是一个 key，缓存页就是对应的 value。用表空间号 + 页号作为 key，缓存页作为 value 创建一个哈希表，在需要访问某个页的数据时，先从哈希表中根据表空间号 + 页号看看有没有对应的缓存页。
如果有，直接使用该缓存页就好。
如果没有，那就从 Free 链表中选一个空闲的缓存页，然后把磁盘中对应的页加载到该缓存页的位置。每当需要从磁盘中加载一个页到 Buffer Pool 中时，就从 Free 链表中取一个空闲的缓存页，并且把该缓存页对应的控制块的信息填上，然后把该缓存页对应的 Free 链表节点从链表中移除，表示该缓存页已经被使用了，并且把该页写入 Lru 链表。
在初始化的时候，Buffer pool 中所有的页都是空闲页，需要读数据时，就会从 Free 链表中申请页，但是物理内存不可能无限增大，数据库的数据却是在不停增大的，所以 Free 链表的页是会用完的。因此需要考虑把已经缓存的页从 Buffer pool 中删除一部分，进而需要考虑如何删除及删除哪些已经缓存的页。
假设一共访问了 n 次页，那么被访问的页在缓存中的次数除以 n 就是缓存命中率，缓存命中率越高，和磁盘的 IO 交互也就越少 。
为了提高缓存命中率，InnoDB 在传统 Lru 算法的基础上做了优化，解决了预读失效和缓存池污染两个问题。
写操作
对于数据库中页的修改操作，首先修改在缓存池中的页，然后在以一定的频率刷新到磁盘，并不是每次页发生改变就刷新回磁盘，而是通过 checkpoint 的机制把页刷新回磁盘。
可以看到，无论是读操作还是写操作，都是对缓存池进行操作，而不是直接对磁盘进行操作。
