《MySQL运维内参》节选
《《MySQL运维内参》节选》要点: 本文上接?InnoDB日志管理机制(一),继续分析buffer pool: 一个BufferPool实例中的所有控制头信息连续存储在一起,所以控制信息存储完成之后才是真正的缓冲页面,下图表示的是一个BufferPool实例的内存分布情况. 对于BufferPool中的所有页面,都有一个控制头信息与它对应,从上图可以看出,每一个ctl都表示了一个属于自己的page使用情况.初始化实例时当然还需要对每一个控制头信息进行初始化,也就是每一个buf_block_t结构.初始化一个页面控制信息是通过buf_block_init函数实现的,buf_block_t结构中包含了很多信息,主要包括如下4部分.
在初始化完每一个页面之后,需要将每一个页面加入到上面提到的空闲页链表中,因为这些页面现在的状态都是未使用(BUF_BLOCK_NOT_USED). 到现在为止,缓冲池的一个实例就算初始化完成了,在访问数据库的时候会通过这些内存页面来缓存文件数据. 相对于整个Buffer Pool而言,多个Buffer Pool实例之间的关系,需要在这里再讲述一下.上面所说的单个实例的初始化,是完全独立的,多个实例之间没有任何关系,单独申请、单独管理、单独刷盘,可以从其实现的代码中看到这一点,代码如下. 从代码中可以看出,每一个Buffer Pool实例在整个Buffer Pool中确实是完全独立的,而在具体使用时,针对不同页面,通过一个HASH算法,来映射到一个具体的实例中,对应的代码如下. 通过Buffer Pool多实例的管理机制,可以减少系统运行过程中不同页面之间一些操作的相互影响,从而很好地解决了由于页面之间的资源争抢导致的性能低下的问题,所以在实际的运维过程中,建议要分多实例的管理方式,把MySQL及InnoDB用好,让业务少一些烦恼. 本文先到这里,下次开始讲REDO LOG,那是一大块……. 文章来自微信公众号:DBAce (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |