网络科技服务有限公司/青岛百度快速优化排名

1. 前言

前面有两篇文章介绍了MySQL的元数据及其缓存管理，其实，元数据的缓存管理也是属于内存管理中的一部分。本篇文章主要介绍数据页的缓存管理机制。

2. Buffer pool

说到缓存管理，首先要说的就是这个buffer pool。所有从磁盘加载进内存的数据页，都会通过这个buffer pool管理起来。对应在代码的中的结构体为buf_pool_t。在MySQL中通常会有多个buffer pool instance，这是为了减少多线程并发访问时，buffer pool锁等待的开销。在MySQL进程初始化时，会初始化每个buffer pool instance，对于每个buffer pool instance：计算buffer pool的chunck数量(=buffer_size/chunck_size)。

/** A chunk of buffers. The buffer pool is allocated in chunks. */

struct buf_chunk_t{

ulintsize;/*!< size of frames[] and blocks[] */

unsigned char*mem;/*!< pointer to the memory area whichwas allocated for the frames */

ut_new_pfx_tmem_pfx;/*!< Auxiliary structure, describing"mem". It is filled by the allocator'salloc method and later passed to thedeallocate method. */

buf_block_t*blocks;/*!< array of buffer control blocks */

/** Get the size of 'mem' in bytes. */

size_tmem_size() const {

return(mem_pfx.m_size);

}

};

2. 初始化LRU list，free list，flush list等。

3. 初始化buffer pool的每个chunck，在函数buf_chunk_init中，初始化每个blocks(在函数buf_block_init)，包括page的实际内容frame，和控制管理信息buf_page_t，然后，将block加入到free list中。

struct buf_block_t{

/** @name General fields */

/* @{ */

buf_page_tpage;/*!< page information; this must

be the first field, so that

buf_pool->page_hash can point

to buf_page_t or buf_block_t */

byte*frame;/*!< pointer to buffer frame which

is of size UNIV_PAGE_SIZE, and

aligned to an address divisible by

UNIV_PAGE_SIZE */

#ifndef UNIV_HOTBACKUP

BPageLocklock;

......

}

在上面的初始化中，出现了buffer pool, chuck, block和frame等几个内存对象，可能初看会比较难以理解，下面笔者作了个图来表示他们之间的关系：

其中，buffer_pool_t结构体中chuncks存有其所有chuck的结构体buffer_chunck_t链表的头部，buffer_chunck_t.mem指向chunck的内存首地址，buffer_chunck_t存有其中所有page的结构控制体buffer_block_t的链表的头部，而对buffer_block_t来说的frame指向page的内存首地址。

3. buffer pool替换管理机制

先说下LRU list，free list和flush list的基本概念。LRU list：以最近最长使用(LRU)的方式，组织InnoDB内存中的所有数据page。

free list：内存中空闲的page，从磁盘读取page时，会从其上取page放入读入内容，并挂到LRU list上进行管理。

flush list：记录内存中被修改的page，称为脏页，因此一个page有可能既在LRU list中，也在flush list中。

当从磁盘读取page时，从free list取出一个page，将磁盘上的内容放入到该page中。对于这个新读入的page，不会首先将其放到LRU list头部，而是会将其放到mid point的位置，一般是离头部5/8的位置，这是为了防止那种全盘一次扫描一个表的情况，而使得LRU list被污染。

如果读取page时，free list没有空闲的page，那么LRU将会从尾部摘除那些没有正在被使用的page，注意这里不是每次只淘汰一个，而是一次淘汰一批，为了防止频繁的替换开销。

MySQL线程后台会有flush线程，定期地将flush list的脏页flush到磁盘上，这样可以减轻check point的开销，和页面替换时，那些被替换页面的flush开销，而使得读取页面时间增长。flush list的页面根据修改的时间从新到老进行排序，也即是最新的修改，在flush list的头部，最老的修改在flush list的尾部。当flush时，从尾部取page flush到磁盘上。这样的逻辑是跟checkpoint保持一致，checkpoint的流程也是从老到新一步步持久化page，所以可以加快checkpoint。