MySQL · 引擎特性 · InnoDB Buffer Pool

布满荆棘的人生 2023-09-30 05:25 5阅读 0赞

![c720c52d1871db6b051879eaebf7f381.png][]

### **前言** ###

用户对数据库的最基本要求就是能高效的读取和存储数据，但是读写数据都涉及到与低速的设备交互，为了弥补两者之间的速度差异，所有数据库都有缓存池，用来管理相应的数据页，提高数据库的效率，当然也因为引入了这一中间层，数据库对内存的管理变得相对比较复杂。本文主要分析MySQL Buffer Pool的相关技术以及实现原理，源码基于阿里云RDS MySQL 5.6分支，其中部分特性已经开源到AliSQL。Buffer Pool相关的源代码在buf目录下，主要包括LRU List，Flu List，Double write buffer, 预读预写，Buffer Pool预热，压缩页内存管理等模块，包括头文件和IC文件，一共两万行代码。

### **基础知识** ###

\*\*\*Buffer Pool Instance: \*\*\* 大小等于innodb\_buffer\_pool\_size/innodb\_buffer\_pool\_instances，每个instance都有自己的锁，信号量，物理块(Buffer chunks)以及逻辑链表(下面的各种List)，即各个instance之间没有竞争关系，可以并发读取与写入。所有instance的物理块(Buffer chunks)在数据库启动的时候被分配，直到数据库关闭内存才予以释放。当innodb\_buffer\_pool\_size小于1GB时候，innodb\_buffer\_pool\_instances被重置为1，主要是防止有太多小的instance从而导致性能问题。每个Buffer Pool Instance有一个page hash链表，通过它，使用space\_id和page\_no就能快速找到已经被读入内存的数据页，而不用线性遍历LRU List去查找。注意这个hash表不是InnoDB的自适应哈希，自适应哈希是为了减少Btree的扫描，而page hash是为了避免扫描LRU List。  
***数据页：*** InnoDB中，数据管理的最小单位为页，默认是16KB，页中除了存储用户数据，还可以存储控制信息的数据。InnoDB IO子系统的读写最小单位也是页。如果对表进行了压缩，则对应的数据页称为压缩页，如果需要从压缩页中读取数据，则压缩页需要先解压，形成解压页，解压页为16KB。压缩页的大小是在建表的时候指定，目前支持16K，8K，4K，2K，1K。即使压缩页大小设为16K，在blob/varchar/text的类型中也有一定好处。假设指定的压缩页大小为4K，如果有个数据页无法被压缩到4K以下，则需要做B-tree分裂操作，这是一个比较耗时的操作。正常情况下，Buffer Pool中会把压缩和解压页都缓存起来，当Free List不够时，按照系统当前的实际负载来决定淘汰策略。如果系统瓶颈在IO上，则只驱逐解压页，压缩页依然在Buffer Pool中，否则解压页和压缩页都被驱逐。  
\*\*\*Buffer Chunks: \*\*\* 包括两部分：数据页和数据页对应的控制体，控制体中有指针指向数据页。Buffer Chunks是最低层的物理块，在启动阶段从操作系统申请，直到数据库关闭才释放。通过遍历chunks可以访问几乎所有的数据页，有两种状态的数据页除外：没有被解压的压缩页(BUF\_BLOCK\_ZIP\_PAGE)以及被修改过且解压页已经被驱逐的压缩页(BUF\_BLOCK\_ZIP\_DIRTY)。此外数据页里面不一定都存的是用户数据，开始是控制信息，比如行锁，自适应哈希等。  
\*\*\*逻辑链表: \*\*\* 链表节点是数据页的控制体(控制体中有指针指向真正的数据页)，链表中的所有节点都有同一的属性，引入其的目的是方便管理。下面其中链表都是逻辑链表。  
\*\*\*Free List: \*\*\* 其上的节点都是未被使用的节点，如果需要从数据库中分配新的数据页，直接从上获取即可。InnoDB需要保证Free List有足够的节点，提供给用户线程用，否则需要从FLU List或者LRU List淘汰一定的节点。InnoDB初始化后，Buffer Chunks中的所有数据页都被加入到Free List，表示所有节点都可用。  
\*\*\*LRU List: \*\*\* 这个是InnoDB中最重要的链表。所有新读取进来的数据页都被放在上面。链表按照最近最少使用算法排序，最近最少使用的节点被放在链表末尾，如果Free List里面没有节点了，就会从中淘汰末尾的节点。LRU List还包含没有被解压的压缩页，这些压缩页刚从磁盘读取出来，还没来的及被解压。LRU List被分为两部分，默认前5/8为young list，存储经常被使用的热点page，后3/8为old list。新读入的page默认被加在old list头，只有满足一定条件后，才被移到young list上，主要是为了预读的数据页和全表扫描污染buffer pool。  
\*\*\*FLU List: \*\*\* 这个链表中的所有节点都是脏页，也就是说这些数据页都被修改过，但是还没来得及被刷新到磁盘上。在FLU List上的页面一定在LRU List上，但是反之则不成立。一个数据页可能会在不同的时刻被修改多次，在数据页上记录了最老(也就是第一次)的一次修改的lsn，即oldest\_modification。不同数据页有不同的oldest\_modification，FLU List中的节点按照oldest\_modification排序，链表尾是最小的，也就是最早被修改的数据页，当需要从FLU List中淘汰页面时候，从链表尾部开始淘汰。加入FLU List，需要使用flush\_list\_mutex保护，所以能保证FLU List中节点的顺序。  
\*\*\*Quick List: \*\*\* 这个链表是阿里云RDS MySQL 5.6加入的，使用带Hint的SQL查询语句，可以把所有这个查询的用到的数据页加入到Quick List中，一旦这个语句结束，就把这个数据页淘汰，主要作用是避免LRU List被全表扫描污染。  
\*\*\*Unzip LRU List: \*\*\* 这个链表中存储的数据页都是解压页，也就是说，这个数据页是从一个压缩页通过解压而来的。  
\*\*\*Zip Clean List: \*\*\* 这个链表只在Debug模式下有，主要是存储没有被解压的压缩页。这些压缩页刚刚从磁盘读取出来，还没来的及被解压，一旦被解压后，就从此链表中删除，然后加入到Unzip LRU List中。  
\*\*\*Zip Free: \*\*\* 压缩页有不同的大小，比如8K，4K，InnoDB使用了类似内存管理的伙伴系统来管理压缩页。Zip Free可以理解为由5个链表构成的一个二维数组，每个链表分别存储了对应大小的内存碎片，例如8K的链表里存储的都是8K的碎片，如果新读入一个8K的页面，首先从这个链表中查找，如果有则直接返回，如果没有则从16K的链表中分裂出两个8K的块，一个被使用，另外一个放入8K链表中。

### **核心数据结构** ###

InnoDB Buffer Pool有三种核心的数据结构：buf\_pool\_t，buf\_block\_t，buf\_page\_t。  
\*\*\*but\_pool\_t: \*\*\* 存储Buffer Pool Instance级别的控制信息，例如整个Buffer Pool Instance的mutex，instance\_no, page\_hash，old\_list\_pointer等。还存储了各种逻辑链表的链表根节点。Zip Free这个二维数组也在其中。  
\*\*\*buf\_block\_t: \*\*\* 这个就是数据页的控制体，用来描述数据页部分的信息(大部分信息在buf\_page\_t中)。buf\_block\_t中第一字段就是buf\_page\_t，这个不是随意放的，是必须放在第一字段，因为只有这样buf\_block\_t和buf\_page\_t两种类型的指针可以相互转换。第二个字段是frame字段，指向真正存数据的数据页。buf\_block\_t还存储了Unzip LRU List链表的根节点。另外一个比较重要的字段就是block级别的mutex。  
\*\*\*buf\_page\_t: \*\*\* 这个可以理解为另外一个数据页的控制体，大部分的数据页信息存在其中，例如space\_id, page\_no, page state, newest\_modification，oldest\_modification，access\_time以及压缩页的所有信息等。压缩页的信息包括压缩页的大小，压缩页的数据指针(真正的压缩页数据是存储在由伙伴系统分配的数据页上)。这里需要注意一点，如果某个压缩页被解压了，解压页的数据指针是存储在buf\_block\_t的frame字段里。

这里介绍一下buf\_page\_t中的state字段，这个字段主要用来表示当前页的状态。一共有八种状态。这八种状态对初学者可能比较难理解，尤其是前三种，如果看不懂可以先跳过。  
\*\*\*BUF\_BLOCK\_POOL\_WATCH: \*\*\* 这种类型的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_po`

[c720c52d1871db6b051879eaebf7f381.png]: https://img-blog.csdnimg.cn/img_convert/c720c52d1871db6b051879eaebf7f381.png