innodb架构图

innodb架构主要由两部分组成：in-memory & on-disk，即内存结构和磁盘结构。

架构图：

这里单独介绍一下磁盘结构。

innodb磁盘结构

1.InnoDB的磁盘结构中表空间的作用？

表空间
是innodb物理存储中最高层。
系统表空间
1）系统表空间
物理文件：ibdata1
系统表空间是一个共享的表空间，该空间数据文件默认是ibdata1，通过如下参数查看：

show variables like '%innodb_data_file_path%';

默认文件名ibdata1、大小12M、自动扩展。
在设定了系统表空间自动扩展后，则不可缩减，即使删除系统表空间中的表和索引，也不会缩减其在磁盘中的大小(只是对已删的做标记)。

2）系统表空间
包含的部分：

• 数据字典：其中包含了表结构信息、数据库名、表名、字段类型和信息、视图、索引、MySQL版本等元数据信息。
• 双写缓冲：用于保证写入磁盘时页数据的完整性，防止发生写失效的问题。
• 修改缓冲：内存中change buffer对应的持久化的区域，也是为了保证数据完整性。
• 回滚日志：记录数据修改前的状态的逻辑日志，实现事务回滚和多版本并发控制。

3）独立表空间
每个表都有自己独立的表空间，每个表的数据和索引都会存在自己的表空间当中。
独立表空间的作用：可以实现单表在不同数据库的文件移动。
独立表空间的存储空间是可以回收的（在删除或清空后）。

4）通用表空间
类似系统表空间，也是共享的，可以存储多个表的数据。相比于独立表空间来说，通用表空间由于是多表共享的空间，消耗的内存更少一点，占用的磁盘空间也会更小一点。
创建通用表空间语法：

create tablespace ts1 add datafile 'ts1.ibd' file_block_size=16384;

file_block_size=16384即指定一页最小16K。文件会被创建在data_dir中。
查看通用表空间语法：

select * from information_schema.innodb_sys_tablespaces where name = 'ts1';

5）回滚表空间
用来保存undo log。undo log默认是保存在系统表空间ibdata1中的，8.0默认有单独的独立表空间文件。
查看回滚表空间路径：

show variables like '%innodb_undo_directory%';

如果显示./则表示默认在系统表空间中，8.0默认表空间名称为undo_001,undo_002。

undo独立表空间设置，0表示不开启undo独立表空间

show variables like '%innodb_undo_tablespaces%';

什么时候需要开启undo的独立表空间？
由于系统表空间不会自动缩减，当出现大事务，undo日志不断增加，ibdata1文件也会不断增大。
所以在5.7中引入一个参数，可以开启undo表空间的自动收缩

show variables like '%innodb_undo_log_truncate%';

默认是OFF。
如果开启则要配置两个或两个以上的undo表空间文件，当有一个写满的时候就会缩减，向另外一个文件继续写入。
MySQL8.0开始对undo表空间进行了分离，初始化后默认就会产生两个undo表空间文件，可进行动态扩容和收缩。

6）临时表空间
用于存储用户创建的临时表，及磁盘内部的临时表。
从MySQL5.7开始采用独立的临时表空间，命名为ibtmp1文件，初始大小为12M，默认无上限。
查看临时表空间文件信息：

select @@innodb_temp_data_file_path;

一般我们还是需要设置一个上限值，避免占用过多磁盘空间。
设置临时表空间大小（例如16M）：

set global tmp_table_size=16*1024*1024;
show variables like '%tmp_table_size%';

当查询使用临时表空间过大，超过设置的上限时会报错。

如何监控临时表和临时表空间的使用情况？

show status like '%tmp%';

其中：

• Created_tmp_disk_tables：表示持久化到磁盘上的临时表数量
• Created_tmp_tables：表示总的临时表数量

用Created_tmp_disk_tables/Created_tmp_tables得出的值不要超过25%。
如果超过了，则应该加大tmp_table_size的值。
此外，重启数据库也会释放tmp表空间。

2.MySQL如何解决写失效问题？

什么是写失效？
Linux文件系统页（OS page）默认大小是4KB，而MySQL的页（Page）默认大小是16KB。
InnoDB的页和操作系统的页大小不一致，InnoDB的页写入磁盘时就需要分4次来写，
这时候，存在一种情况：
如果存储引擎正在写入页的数据到磁盘时发生了宕机，这时如果只是写了一部分页，比如只写了4K就宕机了，这种情况就被叫做写失效。可能会导致数据的丢失，并且这种页数据的损坏靠RedoLog是无法恢复的。

双写缓冲区Doublewrite buffer
参考：

https://blog.csdn.net/qq_26664043/article/details/135718352

用来解决写失效问题，为innodb数据页提供可靠性。实际上是内存+磁盘的结构。

• 内存结构：Doublewrite Buffer内存结构是由128个page页构成的，大小是2MB(16K*128)
• 磁盘结构：Doublewrite Buffer磁盘结构是在系统表空间上，由128个page页构成（2个区，extend1和extend2），大小也是2MB。这些页在磁盘上以Doublewrite File的形式存在。

数据双写的流程：在buffer pool的page页刷新到磁盘真正的位置之前，会将页数据通过memcpy函数拷贝到Doublewrite缓冲区，然后Doublewrite Buffer的内存中的数据页会刷写到Doublewrite Buffer的磁盘上（顺序写，两个连续的1M区域）。这样如果出现宕机，数据页损坏了，但由于双写缓冲区文件是具备一致性的，那么在应用redo log之前，通过该页的副本（在双写缓冲区文件中）来还原该页，然后再进行redo log的重做。因此double write实现了innodb引擎数据页的可靠性。

注：MySQL重启时可以通过校验和来确认是否有错误数据，如果Doublewrite Buffer文件错误了，就从数据文件中拉取原始数据根据redo log得出正确的目标数据，而如果数据文件错误了，则将Doublewrite Buffer中的数据重新写入数据文件。

doublewrite和redo log的关系：
在MySQL的innodb存储引擎中，redo log和double write是配合工作的，确保数据的持久性和恢复能力。
恢复过程中，如果存在损坏的数据页，那么innodb首先就回去双写缓冲区文件中找副本，用副本尝试恢复损坏的数据页，然后再应用重做日志。redo log本质上是物理日志，记录的是 “ 在某个数据页上做了什么修改 ” ，但如果数据页本身已经发生了损坏，redolog来恢复已经损坏的数据块是无效的，数据块的本身已经损坏，再次重做依然是一个坏块。

整个数据页落盘刷新的过程：

• 1.buffer数据页先copy到double write buffer的内存里；
• 2.double write buffer的内存数据刷到double write buffer的磁盘上；
• 3.double write buffer的内存再刷到数据磁盘上；

当MySQL出现异常崩溃时，有如下几种情况发生：

• 情况一：步骤1前宕机，刷盘未开始，数据在redo log，后期可以恢复
• 情况二：步骤1后，步骤2前宕机，因为是在内存中，宕机清空内存，和情况1一样
• 情况三：步骤2后，步骤3前宕机，因为DWB的磁盘有完整的数据，可以修复损坏的页数据

由此我们可以得出结论，double write buffer是针对实际的buffer数据页的原子性保证，就是避免MySQL异常崩溃时，写的那几个data page不会出错，要么都写了，要么什么都没有做。

相关参数：

• innodb_doublewrite：1时启用doublewrite buffer，0时禁用。默认为1。
• innodb_doublewrite_files：定义多少个双写文件。默认为2，范围2到127。
• innodb_doublewrite_dir：双写文件目录。默认为空，即存在数据目录。
• innodb_doublewrite_batch_size：每次批处理操作写入的字节数。默认为，即innodb会选择最佳的批量大小。
• innodb_doublewrite_pages：决定每个双写文件包含多少页。默认128.