持续创作,加速成长!这是我参与「掘金日新计划 · 6 月更文挑战」的第7天,点击查看活动详情
InnoDB存储引擎结构以及重要日志文件简介
1、InnoDB引擎结构图
上图所示可把引擎结构整体上分为两块区域:内存区和磁盘区
2、内存区结构
内存区结构主要包括Buffer Pool、Change Buffer、Adaptive Hash Index(自适应哈希索引)和Log Buffer四个部分;
-
Buffer Pool
-
描述:简单来说Buffer Pool就是一块以16K为大小的Page,组成的链表结构的内存区;通过InnoDB搜索每次回=会读取当前与当前结果所在的同一个页,一次性读取16K的数据到缓冲池中,以此可以减少磁盘IO操作,提升性能;
-
Page页的三种状态:
- clean page:page被使用,但是未被修改,不存在缓存不一致;
- free page:未被使用
- dirty page:被使用且被修改,出现缓存不一致问题
针对于Page的不同状态,分别把他们放入不同的链表集合中;
针对free page是存放于freelist 表示可新增数据的缓存区
cleanpage是存放于LRU list 这个链表存放着当前缓存中正在使用着的,里面存放cleande 和dirty的
dirty page则是存放于flush list 顾名思义那就是刷新列表,将被修改了数据的缓存刷新到吸盘中;内部则是按照修改时间排序;
-
buffer pool不是无限大的,需要一定的额策略进行淘汰
- 一般LRU:采用末尾淘汰法,在链表头部增加新数据,链表满了则采用末尾淘汰
- 改性LRU:链表会被分成new和old两个部分,新增的元素从中间位置( midpoint位置)插入,如果数据很快被访问,那么page就会向new列表头部移动,如果数据没有被访问,会逐步向old尾部移动,等待淘汰。相当于利用元素的的活跃度来对元素排序,高的往前走,低的向后排; 每当有新的page数据读取到buffer pool时,InnoDb引擎会判断是否有空闲页,是有有空间存储,如果有就将free page从free list列表删除,放入到LRU列表中。没有空闲页,就会 根据LRU算法淘汰LRU链表默认的页,将内存空间释放分配给新的页。
-
-
Change Buffer
- 描述:数据库在进行怎删改操作时,通过上文可以得知,数据会被缓存到BP的page,修改数据会把Page更新成dirty,待刷新;但是存在一种情况,此时BP中没有缓存的数据,因此就使用到了Bp,会先在BP中进行更新操作,等下一次查询命令到来,会把相应的数据更新到BP;
- CB实质上也属于B,大约占据1/4的空间,可以通过命令innodb_change_buffer_max_size修改,最大支持到1/2;只适用于非唯一普通页,一旦设置了唯一索引,则会进行索引唯一性的校验,因此无法避免磁盘查询;
-
Adaptive Hash Index 自适应哈希索引;
- InnoDB存储引擎会自动监控对表索引的查找,如果发现建立哈希索引效率会有提升,则会自动建立哈希索引;
-
Log Buffer:日志缓冲区
- 主要是用来保存要写入磁盘上日志文件(Redo/Undo)的数据,日志缓冲区的内容会定期刷新到磁盘log文件中。日志缓冲区满时会自动将其刷新到磁盘,当遇到BLOB 或多行更新的大事务操作时,增加日志缓冲区可以节省磁盘I/O。
3、磁盘结构
-
双写缓冲区(Doublewrite Buffer)
- 位于系统表空间:系统表空间是一块各种表共享的区域,其中包含InnoDB数据字典,Doublewrite Buffer,Change Buffer,Undo Logs的存储区 域,系统表空间也默认包含任何用户在系统表空间创建的表数据和索引数据。
- 默认开启,使用场景就是在BufferPool把脏页数据刷新到磁盘的过程中,会先把数据页存储到双写缓冲区,由此可以预防在数据页写入磁盘的过程中,数据库发生了异常故障问题,会在双写缓冲区有一个备份;
-
Redo Log区
- 是一种基于磁盘的数据结构,用于在崩溃恢复期间更正不完整事务写入的数据。 循环方式写入redo log文件,记录InnoDB中所有对Buffer Pool修改的日志。当遇到某种问题导致数据未能更新到磁盘数据文件,那么在数据库重启时须依据redo log,重新把数据更新到数据文件。读写事务在执行的过程中,都会不断的产生redo log;
-
Undo Log区
用于意外情况时事务回滚,在事务开始之前保存的被修改数据的备份,根据每行记录进行记录。撤消日志存在于系统表空间、撤消表空间和临时表空间中。
磁盘结构有很多组件 暂时先简单介绍这么些比较重要的;
4、重要日志文件简介
-
Undo Log
- 作用:在操作数据库是服务器或其他什么原因异常,导致执行失败,为保证原子性,对当前失败操作的撤销全部状态回滚到数据库操作之前的一个存储日志;MVCC机制的实现依据;
- 产生:在事务开始之前或者刚开始,会把将要操作的数据记录一份带日志;
- 销毁:代事务提交的时候。并不会马上删除,而是把它添加到删除列表,等待后台线程删除;
-
Redo Log
- 以恢复操作为目的,针对事务提交产生的日志 ,在事务中修改操作的数据变动,将最新的数据备份存储到log,为了实现事务的持久性,防止在发生故障的时间点,尚有脏页未写入表 的 IBD 文件中,在重启 MySQL 服务的时候,根据 Redo Log 进行重做,从而达到事务的未入磁盘 数据进行持久化这一特性。
-
Binlog
-
属于一种Mysql数据层面的log日志,主要用来记录数据库中任何的表机构和表数据的变更,它属于二进制日志;
-
主要用于数据的主从数据,和数据恢复工作,Mysql开启了主从备份的模式,从库可以通过这个日志来获取主机的数据,实现同步跟新的作用;
-