文章目录
- 1.InnoDB存储引擎的架构
- 2.InnoDB存储引擎的内存结构
- 2.1.Buffer Pool缓冲池
- 2.2.Change Buffer更改缓冲区
- 2.3.自适应Hash索引
- 2.4.Log Buffer日志缓冲区
- 3.InnoDB存储引擎的磁盘结构
- 3.1.System Tablespace系统表空间
- 3.2.File-Per-Table Tablespaces每个表都有单独的表空间
- 3.3.General Tablespaces通用表空间
- 3.4.Undo Tablespaces撤销表空间
- 3.5.Temporary Tablespaces临时表空间
- 3.6.Doublewrite Buffer Files双写缓冲区
- 3.7.Redo Log重做日志
- 4.InnoDB存储引擎的后台线程
- 4.1.Master Thread核心后台线程
- 4.2.IO Thread IO线程
- 4.3.Purge Thread回收undo log的线程
- 4.4.Page Cleaner Thread协助后台线程刷新脏页到磁盘的线程
- 5.InnoDB的存储引擎的架构连贯
1.InnoDB存储引擎的架构
在MySQL5.5版本之后，默认使用InnoDB作为数据库存储引擎，它擅长事务的处理，具有崩溃恢复的特性，在日常的开发中使用最为广泛。
在InnoDB存储引擎的架构中，由两部分主要组成，分别是内存结构（IN-Memory Structures）和磁盘结构（ON-Disk Structures）。
2.InnoDB存储引擎的内存结构
在InnoDB存储引擎的内存结构中，主要分为四大部分：Buffer Pool（缓冲池）、Change Buffer（更改缓冲区）、Adaptive Hash Index（自适应HASH索引）、Log Buffer（日志缓冲区）。
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 |
+----------------------------------+-------+
2 rows in set (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 |
+------------------------+----------+
1 row in set (0.00 sec)mysql> show variables like 'innodb_flush_log_at_trx_commit';
+--------------------------------+-------+
| Variable_name | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 1 |
+--------------------------------+-------+
1 row in set (0.00 sec)
3.InnoDB存储引擎的磁盘结构
磁盘结构主要分为七个部分，分别是System Tablespace（系统表空间）、File-Per-Table Tablespaces（每个表都有单独的表空间）、General Tablespaces（通用表空间）、 Undo Tablespaces（撤销表空间）、 Temporary Tablespaces（临时表空间）、Doublewrite Buffer Files（双写缓冲区）、Redo Log（重做日志）。
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 |
+-----------------------+------------------------+
1 row in set (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表空间文件。
3.3.General Tablespaces通用表空间
通用表空间，可以示多张表使用一个表空间来存放数据和索引，我们可以创建一个表空间，然后再创建表的时候指定表使用哪一个通用表空间。
创建表空间的语法格式：
CREATE TABLESPACE 表空间名称 ADD DATAFILE '表空间文件路径' BEGIN = '存储引擎名称'
创建表时指定使用哪一个表空间：
CREATE TABLE xxxx TABLESPACE 表空间名称
3.4.Undo Tablespaces撤销表空间
撤销表空间，MySQL实例在初始化的时候，会自动创建两个默认的undo表空间，初始大小为16M，用于存储undo log日志。
[root@mysql ~]# ll /var/lib/mysql/undo_00*
-rw-r----- 1 mysql mysql 33554432 6月 21 23:51 /var/lib/mysql/undo_001
-rw-r----- 1 mysql mysql 33554432 6月 21 23: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 50331648 6月 21 23:54 /var/lib/mysql/ib_logfile0
-rw-r----- 1 mysql mysql 50331648 6月 21 23: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的状态信息。
show engine innodb status \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中的数据会定期回收，不会一直存放在磁盘空间。
