TODO 暂时实现一个，后面再有接着实现多个buffer instance.

正常被使用的数据页都是这种状态。LRU List中，大部分数据页都是这种状态。压缩页被解压后，状态也会变成BUF_BLOCK_FILE_PAGE。.

Buffer Pool中的数据页不仅可以存储用户数据，也可以存储一些系统信息，例如InnoDB行锁，自适应哈希索引以及压缩页的数据等，这些数据页被标记为BUF_BLOCK_MEMORY。处于这个状态的数据页不处于任何逻辑链表中.

当链表处于Free List中，状态就为此状态。是一个能长期存在的状态。.

这种类型的page是提供给purge线程用的。InnoDB为了实现多版本，需要把之前的数据记录在undo log中，如果没有读请求再需要它，就可以通过purge线程删除。换句话说，purge线程需要知道某些数据页是否被读取，现在解法就是首先查看page hash，看看这个数据页是否已经被读入，如果没有读入，则获取(启动时候通过malloc分配，不在Buffer Chunks中)一个BUF_BLOCK_POOL_WATCH类型的哨兵数据页控制体，同时加入page_hash但是没有真正的数据(buf_blokc_t::frame为空)并把其类型置为BUF_BLOCK_ZIP_PAGE(表示已经被使用了，其他purge线程就不会用到这个控制体了)，相关函数buf_pool_watch_set，如果查看page hash后发现有这个数据页，只需要判断控制体在内存中的地址是否属于Buffer Chunks即可，如果是表示对应数据页已经被其他线程读入了，相关函数buf_pool_watch_occurred。另一方面，如果用户线程需要这个数据页，先查看page hash看看是否是BUF_BLOCK_POOL_WATCH类型的数据页，如果是则回收这个BUF_BLOCK_POOL_WATCH类型的数据页，从Free List中(即在Buffer Chunks中)分配一个空闲的控制体，填入数据。这里的核心思想就是通过控制体在内存中的地址来确定数据页是否还在被使用。.

当从Free List中，获取一个空闲的数据页时，状态会从BUF_BLOCK_NOT_USED 变为BUF_BLOCK_READY_FOR_USE(buf_LRU_get_free_block)， 也是一个比较短暂的状态。处于这个状态的数据页不处于任何逻辑链表中。 */.

当加入Free List之前，需要先把page hash移除。因此这种状态就表示此页面page hash已经被移除，但是还没被加入到Free List中，是一个比较短暂的状态。 总体来说，大部分数据页都处于BUF_BLOCK_NOT_USED(全部在Free List中)和BUF_BLOCK_FILE_PAGE(大部分处于LRU List中，LRU List中还包含除被purge线程标记的BUF_BLOCK_ZIP_PAGE状态的数据页)状态，少部分处于BUF_BLOCK_MEMORY状态，极少处于其他状态。前三种状态的数据页都不在Buffer Chunks上，对应的控制体都是临时分配的，InnoDB把他们列为invalid state(buf_block_state_valid)。 如果理解了这八种状态以及其之间的转换关系，那么阅读Buffer pool的代码细节就会更加游刃有余。.

* 这个就是数据页的控制体，用来描述数据页部分的信息(大部分信息在buf_page_t中)。buf_block_t中第一字段就是buf_page_t，这个不是随意放的， 是必须放在第一字段，因为只有这样buf_block_t和buf_page_t两种类型的指针可以相互转换。第二个字段是frame字段，指向真正存数据的数据页。 buf_block_t还存储了Unzip LRU List链表的根节点。另外一个比较重要的字段就是block级别的mutex。 **/.

TODO 用来实现bufferpool* 这个可以理解为另外一个数据页的控制体，大部分的数据页信息存在其中，例如space_id, page_no, page state, newest_modification， oldest_modification，access_time以及压缩页的所有信息等。压缩页的信息包括压缩页的大小，压缩页的数据指针(真正的压缩页数据是存储在由伙伴 系统分配的数据页上)。这里需要注意一点，如果某个压缩页被解压了，解压页的数据指针是存储在buf_block_t的frame字段里。 **/.

脏页.

Discards the least recently used items first.