04 InnoDB存储引擎体系结构

03 InnoDB存储引擎体系结构

1. InnoDB存储引擎体系结构如图所示 

我们可以看到, InnoDB存储引擎体系结构主要包含如下组件, 分为两大部分,内存结构和磁盘结构。 

 

 

 

1. 结构图

从MySQL 5.5版本开始默认使用InnoDB作为引擎,它擅长处理事务,具有自动崩溃恢复的特性,在日常开发中使用非常广泛。下面是官方的InnoDB引擎架构图,主要分为内存结构和磁盘结构两大部分。

在这里插入图片描述

2. InnoDB内存结构

内存结构主要包括Buffer Pool、Change Buffer、Adaptive Hash Index和Log Buffer四大组件。

2.1 Buffer Pool

缓冲池,简称BP。BP以Page页为单位,默认大小16K,BP的底层采用链表数 据结构管理Page。在InnoDB访问表记录和索引时会在Page页中缓存,以后使用可以减少磁 盘IO操作,提升效率。

Buffer Pool: 缓冲池是InnoDB在启动时分配的一个内存区域, 用于InnoDB在访问数据时缓存表和索引数据。 利用缓冲池, 可以合并一些对经常访问的数据的操作, 直接从内存中处理, 加快了处理速度。 通常, 在专用数据库服务器上, 可以将80%的物理内存分配给InnoDB缓冲池。 为了提高缓存管理的效率, 使用页面链表的方式+LRU(最近最少使用) 算法进行管理。(innodb_buffer_pool_size)

  1. Page管理机制 Page根据状态可以分为三种类型:
  1. free page : 空闲page,未被使用
  2. clean page:被使用page,数据没有被修改过
  3. dirty page:脏页,被使用page,数据被修改过,页中数据和磁盘的数据产生了不 一致

针对上述三种page类型,InnoDB通过三种链表结构来维护和管理

  1. free list :表示空闲缓冲区,管理free page
  2. flush list:表示需要刷新到磁盘的缓冲区,管理dirty page,内部page按修改时间排序。脏页即存在于flush链表,也在LRU链表中,但是两种互不影响,LRU链表负责管理page的可用性和释放,而flush链表负责管理脏页的刷盘操作。
  3. lru list:表示正在使用的缓冲区,管理clean page和dirty page,缓冲区以 midpoint为基点,前面链表称为new列表区,存放经常访问的数据,占63%;后面的链表称为old列表区,存放使用较少数据,占37%。
  • 改进型LRU算法维护

普通LRU:末尾淘汰法,新数据从链表头部加入,释放空间时从末尾淘汰
改进LRU:链表分为new和old两个部分,加入元素时并不是从表头插入,而是从中间 midpoint位置插入,如果数据很快被访问,那么page就会向new列表头部移动,如果 数据没有被访问,会逐步向old尾部移动,等待淘汰。
每当有新的page数据读取到buffer pool时,InnoDb引擎会判断是否有空闲页,是否足够,如果有就将free page从free list列表删除,放入到LRU列表中。没有空闲页,就会 根据LRU算法淘汰LRU链表默认的页,将内存空间释放分配给新的页。

  • Buffer Pool配置参数

show variables like ‘%innodb_page_size%’; //查看page页大小
show variables like ‘%innodb_old%’; //查看lru list中old列表参数
show variables like ‘%innodb_buffer%’; //查看buffer pool参数

建议:将innodb_buffer_pool_size设置为总内存大小的60%-80%, innodb_buffer_pool_instances可以设置为多个,这样可以避免缓存争夺。

2.2 Change Buffer:

写缓冲区,简称CB。在进行DML操作时,如果BP没有其相应的Page数据, 并不会立刻将磁盘页加载到缓冲池,而是在CB记录缓冲变更,等未来数据被读取时,再将数 据合并恢复到BP中。

  • ChangeBuffer占用BufferPool空间,默认占25%,最大允许占50%,可以根据读写业务量来进行调整。参数innodb_change_buffer_max_size;

  • 当更新一条记录时,该记录在BufferPool存在,直接在BufferPool修改,一次内存操作。如果该记录在BufferPool不存在(没有命中),会直接在ChangeBuffer进行一次内存操作,不用再去磁盘查询数据,避免一次磁盘IO。当下次查询记录时,会先进性磁盘读取,然后再从 ChangeBuffer中读取信息合并,最终载入BufferPool中。

  • 写缓冲区,仅适用于非唯一普通索引页,为什么?
    如果在索引设置唯一性,在进行修改时,InnoDB必须要做唯一性校验,因此必须查询磁盘, 做一次IO操作。会直接将记录查询到BufferPool中,然后在缓冲池修改,不会在 ChangeBuffer操作。

2.3 Adaptive Hash Index

自适应哈希索引用于优化对BP数据的查询。InnoDB存储引擎会监 控对表索引的查找,如果观察到建立哈希索引可以带来速度的提升,则建立哈希索引,所以 称之为自适应。InnoDB存储引擎会自动根据访问的频率和模式来为某些页建立哈希索引。

2.4 LogBuffer

日志缓冲区,用来保存要写入磁盘上log文件(Redo/Undo)的数据,日志缓冲 区的内容定期刷新到磁盘log文件中。日志缓冲区满时会自动将其刷新到磁盘,当遇到BLOB 或多行更新的大事务操作时,增加日志缓冲区可以节省磁盘I/O。

  • LogBuffer主要是用于记录InnoDB引擎日志,在DML操作时会产生Redo和Undo日志。 LogBuffer空间满了,会自动写入磁盘。可以通过将innodb_log_buffer_size参数调大,减少磁盘IO频率
  • innodb_flush_log_at_trx_commit参数控制日志刷新行为,默认为1

0 : 每隔1秒写日志文件和刷盘操作(写日志文件LogBuffer–>OS cache,刷盘OS cache–>磁盘文件),最多丢失1秒数据
1:事务提交,立刻写日志文件和刷盘,数据不丢失,但是会频繁IO操作
2:事务提交,立刻写日志文件,每隔1秒钟进行刷盘操作

3. InnoDB磁盘结构

InnoDB磁盘主要包含Tablespaces,InnoDB Data Dictionary,Doublewrite Buffer、Redo Log和Undo Logs。

3.1表空间(Tablespaces)

用于存储表结构和数据。表空间又分为系统表空间、独立表空间、通用表空间、临时表空间、Undo表空间等多种类型;

  1. 系统表空间(The System Tablespace)
    包含InnoDB数据字典,Doublewrite Buffer,Change Buffer,Undo Logs的存储区 域。系统表空间也默认包含任何用户在系统表空间创建的表数据和索引数据。系统表空 间是一个共享的表空间因为它是被多个表共享的。该空间的数据文件通过参数 innodb_data_file_path控制,默认值是ibdata1:12M:autoextend(文件名为ibdata1、 12MB、自动扩展)。

  2. 独立表空间(File-Per-Table Tablespaces)
    默认开启,独立表空间是一个单表表空间,该表创建于自己的数据文件中,而非创建于 系统表空间中。当innodb_file_per_table选项开启时,表将被创建于表空间中。否则, innodb将被创建于系统表空间中。每个表文件表空间由一个.ibd数据文件代表,该文件 默认被创建于数据库目录中。表空间的表文件支持动态(dynamic)和压缩 (commpressed)行格式。

  3. 通用表空间(General Tablespaces)
    通用表空间为通过create tablespace语法创建的共享表空间。通用表空间可以创建于mysql数据目录外的其他表空间,其可以容纳多张表,且其支持所有的行格式。
    CREATE TABLESPACE ts1 ADD DATAFILE ts1.ibd Engine=InnoDB; //创建表空 间ts1
    CREATE TABLE t1 (c1 INT PRIMARY KEY) TABLESPACE ts1; //将表添加到ts1 表空间

  4. 撤销表空间(Undo Tablespaces)
    撤销表空间由一个或多个包含Undo日志文件组成。在MySQL 5.7版本之前Undo占用的 是System Tablespace共享区,从5.7开始将Undo从System Tablespace分离了出来。 InnoDB使用的undo表空间由innodb_undo_tablespaces配置选项控制,默认为0。参 数值为0表示使用系统表空间ibdata1;大于0表示使用undo表空间undo_001、 undo_002等。

  5. 临时表空间(Temporary Tablespaces)
    分为session temporary tablespaces 和global temporary tablespace两种。session temporary tablespaces 存储的是用户创建的临时表和磁盘内部的临时表。global temporary tablespace储存用户临时表的回滚段(rollback segments )。mysql服务 器正常关闭或异常终止时,临时表空间将被移除,每次启动时会被重新创建。

3.2数据字典(InnoDB Data Dictionary)

InnoDB数据字典由内部系统表组成,这些表包含用于查找表、索引和表字段等对象的元数 据。元数据物理上位于InnoDB系统表空间中。由于历史原因,数据字典元数据在一定程度上 与InnoDB表元数据文件(.frm文件)中存储的信息重叠。

3.3 双写缓冲区(Doublewrite Buffer)

位于系统表空间,是一个存储区域。在BufferPage的page页刷新到磁盘真正的位置前,会先将数据存在Doublewrite 缓冲区。如果在page页写入过程中出现操作系统、存储子系统或 mysqld进程崩溃,InnoDB可以在崩溃恢复期间从Doublewrite 缓冲区中找到页面的一个好 备份。在大多数情况下,默认情况下启用双写缓冲区,要禁用Doublewrite 缓冲区,可以将 innodb_doublewrite设置为0。使用Doublewrite 缓冲区时建议将innodb_flush_method设 置为O_DIRECT。
MySQL的innodb_flush_method这个参数控制着innodb数据文件及redo log的打开、 刷写模式。有三个值:fdatasync(默认),O_DSYNC,O_DIRECT。设置O_DIRECT表示 数据文件写入操作会通知操作系统不要缓存数据,也不要用预读,直接从Innodb Buffer写到磁盘文件。
默认的fdatasync意思是先写入操作系统缓存,然后再调用fsync()函数去异步刷数据文 件与redo log的缓存信息。

3.4. 重做日志(Redo Log)

重做日志是一种基于磁盘的数据结构,用于在崩溃恢复期间更正不完整事务写入的数据。 MySQL以循环方式写入重做日志文件,记录InnoDB中所有对Buffer Pool修改的日志。当出 现实例故障(像断电),导致数据未能更新到数据文件,则数据库重启时须redo,重新把数 据更新到数据文件。读写事务在执行的过程中,都会不断的产生redo log。默认情况下,重 做日志在磁盘上由两个名为ib_logfile0和ib_logfile1的文件物理表示。

3.5 撤销日志(Undo Logs)

撤消日志是在事务开始之前保存的被修改数据的备份,用于例外情况时回滚事务。撤消日志 属于逻辑日志,根据每行记录进行记录。撤消日志存在于系统表空间、撤消表空间和临时表 空间中。

4. 新版本结构演变

在这里插入图片描述

MySQL 5.7 版本

  • 将Undo日志表空间从共享表空间ibdata文件中分离出来,可以在安装MySQL时由用户自行指定文件大小和数量。
  • 增加了 temporary 临时表空间,里面存储着临时表或临时查询结果集的数据。
  • Buffer Pool 大小可以动态修改,无需重启数据库实例。

MySQL 8.0 版本

    • 将InnoDB表的数据字典和Undo都从共享表空间ibdata中彻底分离出来了,以前需要 ibdata中数据字典与独立表空间ibd文件中数据字典一致才行,8.0版本就不需要了。
    • temporary临时表空间也可以配置多个物理文件,而且均为InnoDB存储引擎并能创建索引,这样加快了处理的速度。
    • 用户可以像 Oracle 数据库那样设置一些表空间,每个表空间对应多个物理文件,每个 表空间可以给多个表使用,但一个表只能存储在一个表空间中。
    • 将Doublewrite Buffer从共享表空间ibdata中也分离出来了。

 

posted @ 2021-04-15 11:37  数据库小白(专注)  阅读(489)  评论(0编辑  收藏  举报