InnoDB存储引擎——缓冲池

缓冲池

虽然InnoDB是基于磁盘存储的，但是由于CPU和磁盘速度的巨大鸿沟，所以对于数据库中的页的修改操作，首先会修改在缓冲池中的页，然后再以一定频率刷新到磁盘上。
具体来看，在缓冲池中占主要（大部分）的是索引页和数据页，但缓冲池还会包含undo页、插入缓冲、自适应哈希索引、InnoDB存储的锁信息、数据字典信息等。

从InnoDB 1.x开始，允许有多个缓冲池实例（默认值为1），每个页根据哈希值被平均分配到不同的缓冲池实例中，减少数据库内部的资源竞争，增加数据库并发处理能力。

缓冲池管理策略：

• LRU
  最频繁使用的在列表的最前端，当缓冲池不能存放新读到的页的时候，首先会释放尾端的页。
  不过InnoDB对LRU做了改进，新加入的页不会直接放到最前端，而是会放到midpoint(默认值为5/8)的位置；并且新加入的页会经历innodb_old_blocks_time才会被加入到LRU的热端。

redo log buffer在之前已经说的很清楚了，为了保证数据不丢失，一般会进行双1设置，参考：高性能Mysql——InnoDB事务是如何通过日志来实现的？。

缓冲池中的三种链

缓冲池的页管理使用三种链完成

• LRU List（用于找到冷端的页）
• Free List（用于找到可用的页）
• Flush List（用于找到最早脏页）

1. 启动时，页数守恒
   当数据库刚刚启动的时候，LRU List是空的，即没有任何的页；这时候，页都存在于Free List中。当需要从缓冲池中分页的时候，首先会从Free List中查找是否有可用的空闲页，若有则从Free List中删除，放入到LRU的列表中；否则会根据LRU算法做淘汰，并且将淘汰页的内存分配给新的页。

2. 修改时，回刷脏页
   在LRU List中的页被修改后，称该页为脏页（dirty page），即缓冲池中的页和磁盘上的页的数据产生了不一致。这时数据库会通过CHECKPOINT机制将脏页刷新回磁盘，而Flush List中的页即为脏页列表。

CheckPoint技术

倘若每一次页发生变化，就将脏页回刷到磁盘，这样的开销是非常大的，若热点数据集中在某几页上，这样数据库的性能也会很差。同时，如果回刷的过程中发生了宕机，那么数据就不可恢复了，为了避免这种情况发生，会使用Write Ahead Log策略，也就是使用redo log先做重写日志，再刷盘。

保证数据的持久化，不能完全依赖于重做日志。因为，重做日志是不能无限增大的，考虑如下的场景：当一个数据库运行了好几个月，这时候发生了当即，那么使用重做日志做数据的重启时间会非常久，代价也会非常大（热启动代价）。

因此，CheckPoint技术是为了解决一下几点：

• 缩短数据库恢复的时间（冷启动）。
• 缓冲池不够用的时候，将脏页回刷。
• 重做日志不可用的时候，将脏页回刷。

当数据库宕机后，此时只需要重做CheckPoint之后的语句即可。

CheckPointer分类：

• sharp checkpoint：完全检查点，数据库正常关闭时，会触发把所有的脏页都写入到磁盘上。
• fuzzy checkpoint：模糊检查点，部分页写入磁盘。

在数据库在运行时不会使用sharp checkpoint，在引擎内部使用fuzzy checkpoint，即只刷新一部分脏页，而不是刷新所有的脏页回磁盘。所以CheckPoint触发的时机，也就是Fuzzy Checkpoint触发的时机。

1. master thread checkpoint
   差不多以每秒或每十秒的速度从缓冲池的脏页列表中刷新一定比例的页回磁盘，这个过程是异步的，不会阻塞用户查询。
2. flush_lru_list checkpoint
   MySQL会保证LRU List里面有差不多100个空闲页。如果没有100个可用空闲页，那么innodbhi将lru list尾端的页移除，如果这些页中有脏页，那么需要进行checkpoint。
3. async/sync flush checkpoint
   重做日志不可用时（满了），会将一些页回刷。
4. dirty page too much checkpoint
   脏页太多，进行回刷，总的来说还是保证缓冲池有足够可用的页。