山西两学一做网站登录,浏览器官网,wordpress超级排版器插件,wordpress 基础seo建站文章目录 1、前置知识1.1、Buffer Pool介绍1.2、后台线程1.2.1、Master Thread1.2.2、IO Thread1.2.3、Purge Thread1.2.4、Page Cleaner Thread 1.3、重做日志缓冲池 2、Buffer Pool 组成2.1、数据页2.2、索引页2.3、undo页2.4、插入缓冲2.5、锁空间2.6、数据字典2.6、自适应哈… 文章目录 1、前置知识1.1、Buffer Pool介绍1.2、后台线程1.2.1、Master Thread1.2.2、IO Thread1.2.3、Purge Thread1.2.4、Page Cleaner Thread 1.3、重做日志缓冲池 2、Buffer Pool 组成2.1、数据页2.2、索引页2.3、undo页2.4、插入缓冲2.5、锁空间2.6、数据字典2.6、自适应哈希索引 3、Buffer Pool 内存管理3.0、控制块3.1、Free List3.2、Flush List3.3、LRU List 1、前置知识
1.1、Buffer Pool介绍
MySQL数据库具有可拔插的存储引擎其中最常用的是InnoDB而Buffer Pool缓冲池是InnoDB存储引擎中特有的内存结构MySQL向操作系统内存申请一块内存空间用于Buffer Pool缓冲池使用因为硬盘和内存性能差距大所以Buffer Pool缓冲池用于协调CPU速度和硬盘速度的鸿沟Buffer Pool大幅度提升MySQL数据库的读写性能。
按照我们的惯性思维这里会有一个疑问不都说MySQL的数据是基于硬盘存储吗为什么这里会提到Buffer Pool缓冲池内存这概念 MySQL当然是通过硬盘持久化存储Buffer Pool 并不是 MySQL 真正意义上存储数据的单元载体。 MySQL仅仅是借助Buffer Pool提升读写性能毕竟内存的访问速度要比硬盘快得多这并不冲突。 我们进行数据的查询操作MySQL并不是直接从硬盘文件中查找对应的数据信息会先查看Buffer Pool中是否有想要查询数据。如果有直接返回给用户如果没有去硬盘中的查询想要的数据。查询到结果后会同步到Buffer Pool中下次用户再次发起查询就不用访问磁盘了修改操作也是同理先操作Buffer Pool中的数据然后数据刷入硬盘的文件中有点像Redis我们先站在操作系统维度看看 Buffer Pool 在内存中的样貌
Buffer Pool缓冲池有数据页硬盘中MySQL表数据加载到Buffer Pool中就是通过数据页来存放的Buffer Pool默认大小128MBInnoDB存储引擎已经将硬盘中的数据划分为一个个页默认大小16KB通过页为基本单位进行硬盘与内存之间的交互。
上面提到了查询、修改等SQL操作无论是Buffer Pool将修改的页刷盘到硬盘还是从硬盘加载到Buffer Pool都是以数据页为单元进行操作的而不是操作页中的某几行数据。
这里有个注意点Buffer Pool缓冲池并不是只有一个的可以申请多个内存区域作为缓冲池同时工作。
1.2、后台线程
之前提到一个概念叫做刷盘意思是Buffer Pool中缓存页数据会异步刷新到硬盘中保证了数据的一致性后台线程的主要作用就是对缓冲池中的页进行进行操作。InnoDB存储引擎后台线程主要有以下几种
1.2.1、Master Thread
该线程主要用于将Buffer Pool 缓冲池中的数据进行刷盘保证数据一致性。主要主责包括脏页刷盘、插入缓冲合并、undo页回收等。
1.2.2、IO Thread
该线程主要用于处理AIOAsync IO请求回调因为InnoDB存储引擎中存在大量的异步IO操作IO Thread可以极大数据库性能。
1.2.3、Purge Thread
当事务提交之后undo页就没有任何存在的意义了该线程主要职责就是回收无用的undo页。
上面1.2.1 Master Thread中提到Master Thread主要职责就包括了回收undo页但是后续InnoDB版本开始将部分purge操作交给Purge Thread来完成减少Master Thread的工作压力提升性能。也就是说回收undo页功能Master Thread和Purge Thread都具备该线程就是为了替Master Thread分担回收undo页的工作压力。
1.2.4、Page Cleaner Thread
该线程也是为Master Thread分担工作压力提升数据库性能。不过Page Cleaner Thread分担了什么压力呢脏页刷盘操作。
1.3、重做日志缓冲池
硬盘中存在重做日志文件主要用于故障恢复保证MySQL事务的持久性重做日志缓冲池就是用于存放重做日志信息然后按照一定频率刷盘重做日志文件中常用于数据库的故障恢复场景这并不是本文章的重点。
2、Buffer Pool 组成
2.1、数据页
当我们进行查询的数据不在缓冲池中时就会将磁盘中的数据对应的页加载到Buffer Pool中这就是数据页。当我们对数据页内容进行修改此时数据页就会变成脏页而不是直接操作硬盘中的文件页只需要将脏页刷新到磁盘中这样通过页为单位交互性能好很多。
2.2、索引页
Buffer Pool缓冲池中不仅会存放数据页还会存放索引页。
之所以这样是因为我们不能保证每次查询操作都能从缓冲池的数据页中拿到想要的结果此时就需要对磁盘中数据文件进行IO访问操作。如果本次的查询操作命中了索引我们又该如何知道索引的根节点到底在磁盘中的哪个位置呢这个时候就需要索引页来帮助我们当MySQL实例启动时就会将数据库中的索引根节点放入到缓冲池的索引页中当我们的查询SQL命中了索引就不需要在整个磁盘中查找对应的索引根节点了
2.3、undo页
undo页主要记录事务回滚操作信息常用于事务回滚操作。
事务如何通过undolog进行回滚操作呢这个很好理解我们只需要在undolog日志中记录事务中的反向操作即可例如 事务进行insert操作undolog记录delete操作 事务进行delete操作undolog记录insert操作 事务进行update操作a改为bundolog记录update操作b改为a 2.4、插入缓冲
插入缓冲只针对非聚集、不唯一索引页增、删、改操作。
当我们对非聚集、不唯一索引页进行插入、修改操作时不是直接操作索引页而是先判断当前索引页是否在Buffer Pool缓冲池中如果在直接操作索引页即可如果不在就放入Insert Buffer对象中然后以一定频率进行插入缓冲和辅助索引页合并操作大大提升非聚集索引操作性能
那为什么聚集索引或者说主键索引不需要插入缓冲因为主键索引插入操作是按照主键顺序递增的属于顺序插入不需要随机读取硬盘性能很快。
2.5、锁空间
锁空间就是专门用来存储锁结构、并发事务的链表的一块内存区域这里不过多介绍。
2.6、数据字典
MySQL数据库启动时会自动从硬盘中将系统表相关信息加载到Buffer Pool缓冲池中有了数据字典这样当我们使用show index、show tables相关命令就能查到表、索引相关的信息主要分为以下 SYS_TABLES存储所有InnoDB表信息。 SYS_COLUMNS存储所有用户定义的表字段信息。 SYS_INDEXES存储所有InnoDB引擎表索引信息。 SYS_FIELDS存储所有索引的定义信息。 2.6、自适应哈希索引
默认情况下我们的索引页采用BTree的结构大幅度提高我们对数据库的查询性能虽然性能已经很好了但是自适应哈希索引的性能棒不得了O(1)时间复杂度查询性能非常高。
自适应哈希索引不需要我们主动人为干涉它是InnoDB自动生成的自适应哈希索引针对是热点索引页而不是整张表并且生成的条件也比较苛刻。当我们对某个索引页连续的访问模式条件一样访问模式例如 where a xxx where a xxx and b yyy 上面举例这两种访问模式不能交替执行否则也不会生成自适应哈希索引那何时自动生成呢有以下两种情况 以某个模式访问100次 以某个模式访问 n 次n 页中记录 / 16 3、Buffer Pool 内存管理
3.0、控制块
InnoDB在操作系统中为Buffer Pool缓冲池申请创建了一块连续的内存内存被划分成一块块缓冲页之前提过缓冲池是以页为基本单位与磁盘进行交互InnoDB存储引擎为缓冲池中每个缓冲页都生成了一个控制块一对一关系。
控制块中记录了数据页所属的表空间、页号、缓冲页地址、链表节点指针等信息。控制块和缓存页关系图如下发现图中有个内存碎片这是因为缓冲池剩余空间不够一对控制块和缓存页的大小这点剩余内存空间就被称为内存碎片
3.1、Free List
Buffer Pool缓冲池内存被划分为一个个页但并不是所有页都被使用有一些页是处于空闲状态的没存数据这种空闲页会被Free List进行管理方便快速查找使用。
当硬盘中的页刷入到Buffer Pool缓冲池中时就会从Free List中查找是否有空闲页如果有就将空闲页从Free List中取出使用移除如果没有就会使用后续提到的LRU List列表的尾部的数据页。下图中头节点解释 head指针指向 Free List 的第一个控制块。 ail指针指向 Free List 的最后一个控制块。 count数字记录 Free List 的节点数量。 3.2、Flush List
之前提到过脏页刷盘这个操作所谓脏页就是缓冲池中缓存页中内容发生了改变修改、删除、新增此时这个该页就称为脏页。脏页数据和磁盘中文件数据是不一致的需要后台线程将数据异步刷新到磁盘中。这些脏页的管理就需要Flush List结构图跟3.1 Free List大同小异这里就不重复画了。
3.3、LRU List
知道了Free List维护空闲页Flush List维护脏页那么LRU List维护的是什么页
LRU List用来管理已经读取的页所以当数据库刚启动时LRU List也是空的这时候的空闲页都在Free List中当需要从硬盘中加载数据页到Buffer Pool时就会从Free List查找是否有空闲页可以使用如果没有空闲页就根据LRU算法淘汰LRU List尾部页将内存空间分配给新页。
硬盘中的页加载到缓冲池中没有任何修改操作那就说这个缓冲页是干净的干净页或者说脏页数据刷盘到磁盘后就变成了干净页。不过有一点需要强调当我们对干净页进行修改操作时也就是它变成了脏页此时脏页也不会从LRU List中移除这个脏页将会同时存在于LRU List和Flush List中。 关于脏页是否同时在LRU、Flush List中存在这里有些争议有些人认为脏页不在LRU List中记录只在Flush List中记录 不过《MySQL技术内幕 InnoDB存储引擎》这本书中介绍的是脏页既存在于LRU List也存在于Flush List LRU List管理缓存页是通过LRU算法就是说访问频率低最近最少使用的缓存页将会放到LRU List列表尾部访问频率比较高的热点页将会放到LRU List首部当可用的空闲页不足时就会淘汰LRU List链表末尾的数据页。我们先来看下LRU List大致是什么样子 LRU List的LRU算法跟常规的LRU算法是有区别的InnoDB之所以使用特殊的LRU算法主要是考虑到传统的LRU算法有这两个问题 预读无效Buffer Pool污染 预读的意思是 Buffer Pool 在加载数据页时会把它相邻的数据页一起加载到缓冲池中目的是减少了磁盘IO操作。不过常规LRU算法会将预读的数据页也放置到LRU List头部这样可能出现预读数据页几乎不会使用到大大降低LRU List的使用性能。
Buffer Pool污染大概也是这个意思如果偶尔做一次大数据量的表查询操作全表扫描直接出现许多不常用数据页在LRU List头部导致本身的热点页被移除。降低了LRU List使用性能。
针对以上常规LRU算法所带来的问题LRU List是用了特殊LRU算法。上图中可以看到midpoint通过midpoint为分界线将midpoint左侧数据页区域称为NEW区右侧称为OLD区。NEW区域的数据页是经常使用、访问的这些数据页我们称之为热点页midpoint位于LRU List链表的5/8处37 : 63这个比例可以通过参数innodb_old_blocks_pct调整这样我们最新访问的数据页不会直接放到NEW区域的头部而是放到OLD区域的头部。
那么什么时候会从OLD区移动到NEW区呢InnoDB存储引擎通过一个时间参数innodb_old_blocks_time控制页读取到midpoint位置时等待多久才会加入到NEW区这个时间默认为1000ms。如果后续的访问时间与第一次访问的时间不在这个时间间隔内那么该缓存页就会移动到 NEW 区域的头部这就是LRU List管理缓存页的方式。
