0


深入探讨MySQL数据库的InnoDB存储引擎架构

文章目录

1.InnoDB存储引擎的架构

在MySQL5.5版本之后,默认使用InnoDB作为数据库存储引擎,它擅长事务的处理,具有崩溃恢复的特性,在日常的开发中使用最为广泛。

在InnoDB存储引擎的架构中,由两部分主要组成,分别是内存结构(IN-Memory Structures)和磁盘结构(ON-Disk Structures)。

image-20220623230441277

2.InnoDB存储引擎的内存结构

在InnoDB存储引擎的内存结构中,主要分为四大部分:Buffer Pool(缓冲池)、Change Buffer(更改缓冲区)、Adaptive Hash Index(自适应HASH索引)、Log Buffer(日志缓冲区)。

image-20220623131249287

2.1.Buffer Pool缓冲池

内存结构中最主要的就是Buffer Pool缓冲池了,InnoDB存储引擎是基于磁盘文件存储数据的,访问磁盘的效率和访问内存的效率,两者之间的速度相差是非常大的,为了尽可能的弥补磁盘和内存之间I/O效率差值,通常情况下就是将磁盘中的数据加载到内存中的缓冲池里面,避免频繁访问磁盘影响磁盘I/O的性能。

Buffer Pool缓冲池是内存中的一个区域,可以缓存磁盘中经常需要被操作的数据,当执行增删改查这类操作时,会先操作缓冲池中的数据,如果缓冲池中没有数据,将会从磁盘中加载数据并缓存到缓冲池,数据在缓存池中被处理之后,再通过一定的频率刷新到磁盘中,从而减少磁盘IO,加快处理速度。

如上图所示,在缓冲池中看到有很多歌小方块,这个表示Page页,缓冲池的单位也是Page页。底层会采用链表数据结构管理所有的Page页。

在缓冲池中的Page分为三种类型:(图中将每种类型的Page以不同颜色区分)

  • free page:空闲page,未被使用的页。
  • clean page:被使用的page,但是里面的数据没有被修改过。
  • dirty page:脏页,被使用的page,并且里面的数据修改过,但是还没有刷新到磁盘,与磁盘中的数据产生了不一致。

在InnoDB的缓冲池中不仅缓存了索引页和数据页,还包含了undo页、插入缓存、自适应哈希、InnoDB的锁信息等。

2.2.Change Buffer更改缓冲区

Change Buffer是更改缓冲区,主要是针对二级索引打造的,当执行DML增删改的语句时,如果操作的数据Page页没有在Buffer Pool缓冲池中,那么不会直接从操作磁盘中的数据,而是将数据变更后的内容存放在更改缓冲区中。当未来被操作的数据被Buffer Pool缓冲池读取到了,此时再讲Change Buffer更改缓冲区中更改的内容与Buffer Pool中的数据进行合并回复,最后通过一定的频率,将合并后的数据刷新到磁盘中。

Change Buffer简单来说就是当DML语句操作的数据不在缓冲池时,将语句对数据更改后的内容记录在Change Buffer更改缓冲区中,然后当要操作的数据被读取到缓冲池后,再将更改缓冲区中的数据与缓冲池中的数据合并,最后刷新到磁盘。

我们来思考一下,Change Buffer更改缓冲区有什么作用呢?当Buffer缓冲池没有数据时,直接读取磁盘的数据进行更不行吗?当然是不行的,因为二级索引通常都是非唯一的,并也是以相对随机的顺序写入到二级索引中,同样当删除和更新时,就会影响索引结构中不相邻的二级索引页,如果每次更改数据都直接操作磁盘,那么也会造成大量的磁盘I/O消耗,从而影响性能。

2.3.自适应Hash索引

自适应Hash索引主要是用来优化Buffer Pool缓冲池中的数据查询的,MySQL的InnoDB不支持Hash索引数据结构,Hash索引结构中等值匹配的检索效率远远超过B+Tree,因为Hash索引只需要一次IO就可以检索到数据,而B+Tree则需要多次匹配,所以Hash索引的效率要远超B+Tree。

虽然InnoDB不支持Hash索引的数据结构,但是却提供了自适应H时候索引的功能,在进行等值匹配时,依然可以具备Hash索引的效率。

InnoDB存储引擎会监控对表上各索引页的查询,如果观察到在特定的条件下hash索引可以提升速度,则建立hash索引,称之为自适应hash索引。

Hash不适合做范围查询和模糊匹配。

自适应哈希索引,无需人工干预,统统由系统根据情况自动判断。

通过以下命令可以看到自适应哈希有没有开启。
mysql>show variables like'%adaptive_hash_index%';+----------------------------------+-------+| Variable_name                    |Value|+----------------------------------+-------+| innodb_adaptive_hash_index       |ON|| innodb_adaptive_hash_index_parts |8|+----------------------------------+-------+2rowsinset(0.01 sec)

2.4.Log Buffer日志缓冲区

Log Buffer是日志缓冲区,这个日志缓冲区并不是我们理解的日志,在InnoDB存储引擎中会将要写入磁盘中的数据(redo )保存在日志缓冲区中,默认的大小为16MB,日志缓冲区的日志会定期刷新到磁盘中,如果需要更新、插入或者删除等等很多事务时,可以适当增大日志缓冲区的大小。

通过日志缓冲区可以节省磁盘I/O。

日志缓冲区可设置的参数:

  • innodb_log_buffer_size:设置缓冲区的大小
  • innodb_flush_log_at_trx_commit:日志刷新到磁盘的策略,共包含三个值: - 1:每次事务提交时将数据写入到日志缓冲区,并刷新到磁盘,默认值。- 0:每秒将数据写入到日志缓冲区并刷新到磁盘一次。- 2:每次事务提交时将数据写入到日志缓冲区,并且每秒刷新到磁盘一次。
mysql>show variables like'innodb_log_buffer_size';+------------------------+----------+| Variable_name          |Value|+------------------------+----------+| innodb_log_buffer_size |16777216|+------------------------+----------+1rowinset(0.00 sec)

mysql>show variables like'innodb_flush_log_at_trx_commit';+--------------------------------+-------+| Variable_name                  |Value|+--------------------------------+-------+| innodb_flush_log_at_trx_commit |1|+--------------------------------+-------+1rowinset(0.00 sec)

3.InnoDB存储引擎的磁盘结构

磁盘结构主要分为七个部分,分别是System Tablespace(系统表空间)、File-Per-Table Tablespaces(每个表都有单独的表空间)、General Tablespaces(通用表空间)、 Undo Tablespaces(撤销表空间)、 Temporary Tablespaces(临时表空间)、Doublewrite Buffer Files(双写缓冲区)、Redo Log(重做日志)。
image-20220623230524330

3.1.System Tablespace系统表空间

系统表空间是Change Buffer更改缓冲区的存储区域,更改缓冲区中的数据都在系统表空间中,如果MySQL系统中的表没有自己独立的表空间文件,或者也没有使用通用表空间,此时系统表空间就是该表的表空间。

系统表空间中可能会包含表和索引数据,在MySQL5.x版本中还包含InnoDB数据字典、undolog等。

查看系统表空间路径:

mysql>show variables like'innodb_data_file_path';+-----------------------+------------------------+| Variable_name         |Value|+-----------------------+------------------------+| innodb_data_file_path | ibdata1:12M:autoextend |+-----------------------+------------------------+1rowinset(0.01 sec)#默认的系统表空间文件是ibdata1[root@mysql~]# ll /var/lib/mysql/ibdata1 -rw-r----- 1 mysql mysql 12582912 6月  21 23:49 /var/lib/mysql/ibdata1

3.2.File-Per-Table Tablespaces每个表都有单独的表空间

如果开启了Innodb_file_per_table参数后,每个表都会有独立的表空间文件,在表空间文件中包含了这张表的数据和索引。该参数默认开启。

mysql>show variables like'innodb_file_per_table';+-----------------------+-------+| Variable_name         |Value|+-----------------------+-------+| innodb_file_per_table |ON|+-----------------------+-------+

每个表都有单独的ibd表空间文件。

image-20220623232054941

3.3.General Tablespaces通用表空间

通用表空间,可以示多张表使用一个表空间来存放数据和索引,我们可以创建一个表空间,然后再创建表的时候指定表使用哪一个通用表空间。

创建表空间的语法格式:

CREATETABLESPACE 表空间名称 ADD DATAFILE '表空间文件路径'BEGIN='存储引擎名称'

创建表时指定使用哪一个表空间:

CREATETABLE xxxx TABLESPACE 表空间名称

3.4.Undo Tablespaces撤销表空间

撤销表空间,MySQL实例在初始化的时候,会自动创建两个默认的undo表空间,初始大小为16M,用于存储undo log日志。

[root@mysql ~]# ll /var/lib/mysql/undo_00*
-rw-r----- 1 mysql mysql 335544326月  2123:51 /var/lib/mysql/undo_001
-rw-r----- 1 mysql mysql 335544326月  2123:54 /var/lib/mysql/undo_002

3.5.Temporary Tablespaces临时表空间

InnoDB使用会话临时表空间和全局临时表空间,存储用户创建的临时表的数据。

3.6.Doublewrite Buffer Files双写缓冲区

双写缓冲区,InnoDB引擎将数据页从Buffer Pool缓冲池刷新到磁盘之前,还会将数据页写入到双写缓冲区中,便于系统异常时,可以恢复数据。

[root@mysql ~]# ll /var/lib/mysql/#ib_16384_*
-rw-r----- 1 mysql mysql  196608 6月  21 23:54 /var/lib/mysql/#ib_16384_0.dblwr
-rw-r----- 1 mysql mysql 8585216 6月  21 23:41 /var/lib/mysql/#ib_16384_1.dblwr

3.7.Redo Log重做日志

重做日志用来实现事务的持久性,该日志文件由两部分组成:重做日志缓冲(redo log buffer)以及重做日志文件(redo log),前者是在内存中,后者是在磁盘中,当事务提交之后,会把所有修改的信息存放在该日志中,当刷新脏页数据到磁盘时,发送了错误,可以通过日志文件进行数据的恢复。

[root@mysql ~]# ll /var/lib/mysql/ib_logfile*
-rw-r----- 1 mysql mysql 503316486月  2123:54 /var/lib/mysql/ib_logfile0
-rw-r----- 1 mysql mysql 503316486月  2123:54 /var/lib/mysql/ib_logfile1

4.InnoDB存储引擎的后台线程

在InnoDB的后台线程中,主要分为四类:Master Thread(核心后台线程) 、IO Thread(IO线程)、Purge Thread(回收undo log的线程)、Page Cleaner Thread(协助后台线程刷新脏页到磁盘的线程)

4.1.Master Thread核心后台线程

核心后台线程主要负责调度其他的线程,还负责将缓冲池中的数据异步刷新到磁盘中,保持数据的一致性,还包括脏页的刷新、合并插入缓存、undo页的回收等。

4.2.IO Thread IO线程

在InnoDB的存储引擎中使用了大量的AIO来处理IO请求,这样可以极大的提高数据库的性能,而IO线程主要负责这些IO请求的回调。

IO线程又分为四类:

  • Read Thread:负责读操作。默认4个
  • Write Thread:负责写操作。默认4个
  • Log Thread:负责将日志缓冲区刷新到磁盘。默认1个
  • Insert Buffer Thread:负责将写缓冲区的内容刷新到磁盘。默认1个

可以通过以下命令查看InnoDB的状态信息。

showengineinnodbstatus \G;

4.3.Purge Thread回收undo log的线程

主要用于回收undo log的线程,当事务已经提交了,undo log可能就不再使用了,如果不回收,会占用大量的磁盘空间。

4.4.Page Cleaner Thread协助后台线程刷新脏页到磁盘的线程

协助核心后台线程刷新脏页数据到磁盘的线程,可以减轻Master Thread的工作压力,减少阻塞。

5.InnoDB的存储引擎的架构连贯

在前面已经讲解了InnoDB的内存结构和磁盘结构以及后台线程,那么一起来看一下InnoDB架构到底是如何工作的。

如下图所示:用户操作数据库表中的数据时,首先在内存结构的缓冲区里找到对应的数据,如果缓冲区中没有要处理的数据,那么会从磁盘的表空间文件里加载数据到缓冲区,当我们增删改查时,都是在缓冲区里操作的,当数据处理完毕后,经过一定的频率通过一组后台线程,将数据刷新到磁盘中的表空间里,进行数据的持久化。

Undo log和Redo log中的数据会定期回收,不会一直存放在磁盘空间。

image-20220623235212782


本文转载自: https://blog.csdn.net/weixin_44953658/article/details/134004082
版权归原作者 Jiangxl~ 所有, 如有侵权,请联系我们删除。

“深入探讨MySQL数据库的InnoDB存储引擎架构”的评论:

还没有评论