ファイルには、先に説明したMySQLデータベースファイル自体、およびストレージエンジンとは無関係です。この記事では説明関連のユニークなファイルストレージエンジンを。この記事では、これらのファイルには、密接にはInnoDBに関連するファイルについて説明し、REDOログ・ファイル、テーブルスペースファイルを

まず、テーブル・スペース・ファイル

関数： InnoDBは使用して、ストレージの表スペース（TABLESPACE）によって格納されたデータの設計を
では、最初の10メガバイトのサイズ、idbata1ファイル名（下記参照）を持つことになりますデフォルトの設定、ファイルには、デフォルトのファイル表領域があります

innodb_data_file_pathパラメータ

このパラメータを指定InnoDBテーブルスペースファイルが使用します。このパラメータを設定した後、全てのInnoDBデータが共有空間テーブルに記録されるストレージエンジンのテーブルに基づいて

たとえば、次の表は、デフォルトのInnoDBが使用するファイル・スペースを示します
show variables like 'innodb_data_file_path'\G;
パラメータの形式は次のとおりです。

あなたがしたい場合は、テーブルスペースに複数のファイルを渡すと、プロパティファイルを開発するには、次の形式の例を使用することができます。

ここでは/ DB / ibdata1とおよび/ DR2 / DB / ibdata2 表領域を形成するために用いられる二つのファイル。この2つのファイルを別のディスクに配置されている場合は、ディスクの負荷が平均かもしれないが、することが可能であるデータベースの全体的なパフォーマンスを向上させます

同じ時間で、ファイル名も、ファイルサイズ属性の後ろに行ってきました。この2000メガバイトが不足した場合ibdata1とのサイズは2000メガバイト、2000メガバイトのibdata2サイズであることを示し、ファイルが自動的に増加します

innodb_file_per_tableをパラメータ

このパラメータが設定されている場合、ユーザができ、各 InnoDBストレージエンジンに基づいて、テーブルを生成する独立した表領域。このように、ユーザは、すべてのデータがデフォルトの表スペースに保管されていません。このパラメータはデフォルトではオフになって、別の表スペース・ファイルを使用していません
show variables like 'innodb_file_per_table'\G;
別の表スペースの命名規則は次のとおりです。テーブル名の.ibd

これらの別々の表領域ファイルのことを注意のみを格納テーブルのデータ、インデックス、挿入バッファBITMAP情報は、情報の残りの部分はデフォルトの表スペースに格納されます。次の図は、InnoDBストレージエンジンのためのファイルの保存を示しています。

このMySQLデータベースサーバーの設定の下には、このパラメータを観察することができます。

InnoDB内で記憶されたテーブルに基づいて、T2テーブルプロファイル、T1、

パラメータinnodb_file_per_tableを= ONするので、このように別個の独立したテーブルスペースファイルを作成するの.ibd

第二に、REDOログ・ファイル（REDOログ）

REDOログ・ファイルについて：
- デフォルトでは、 InnoDBストレージエンジンの下のデータディレクトリが持っているib_logfile0とib_logfile1という名前の2つのファイルを。MySQLのInnoDBストレージエンジンのログファイルの公式マニュアルに言ってますが、より正確な定義は、必要があるログファイルをやり直し（REDOログ・ファイル）
- なぜそれがREDOログ・ファイルを強調しますか？InnoDBストレージエンジンのREDOログ・ファイルが必要不可欠であるため、彼らはInnoDBストレージエンジンのトランザクションログを記録します
- 当实例或介质失败时，重做日志文件就能派上用场。例如，数据库由于所在主机掉电导致实例失败，InnoDB存储引擎会使用重做日志文件恢复到掉电前的时刻，以此来保证数据的完整性

重做日志文件组的概念

每个InnoDB存储引擎至少有1个重做日志文件组。每个文件组下至少有2个重做日志文件（如默认的ib_logfile0和ib_logfile2）

为了得到更高的可靠性，用户可以设置多个的镜像日志组，将不同的文件组放在不同的磁盘上，以此来提高重做日志高可用性

在日志组中每个重做日志文件的大小一致，并以循环写入的方式运行。例如：InnoDB有3个重做日志文件。InnoDB先写重做日志文件0，当文件0写满后，接着写重做日志文件1，当文件1写满后，开始重写日志文件2，当重写日志文件2写满后，又开始写重做日志文件0。下图显示了一个拥有3个重做日志文件的重做日志文件组

innodb_log_file_size参数

该参数指定每个重做日志文件的大小

在InnoDB 1.2.x之前，重做日志文件总的大小不得大于等于4GB，而1.2.x版本将该限制扩大为了512GB
show variables like 'innodb_log_file_size'\G;
innodb_log_files_in_group参数

该参数指定了日志文件组中重做日志文件的数量。默认为2
show variables like 'innodb_log_files_in_group'\G;
innodb_mirrored_log_groups参数

该参数指定了日志镜像文件组的数量

默认为1，表示只有一个日志文件组，没有镜像。若磁盘本身已经做了高可用的方案，如磁盘列阵，那么可以不开启重做日志镜像的功能
show variables like 'innodb_mirrored_log_groups'\G;
innodb_log_group_home_dir参数

该参数指定了日志文件组所在路径

默认为“./”，表示在MySQL数据库的数据目录下
show variables like 'innodb_log_group_home_dir'\G;

重做日志文件的大小问题

上面介绍了innodb_log_file_size参数用来决定每个重做日志文件的大小。重做日志文件的大小设置对于InnoDB存储引擎的性能有着非常大的影响：

一方面，重做日志文件不能设置的太大，如果设置得很大，在恢复时可能需要很长的时间

另一方面，重做日志文件又不能设置的太小，否则可能导致一个事务的日志需要多次切换重做日志文件

此外，重做日志文件太小会导致频繁地发生async checkpoint（见文章：https://blog.csdn.net/qq_41453285/article/details/104091059），导致性能的抖动

例如，用户可能在错误日志中看到如下警告信息：

下面的错误集中在前两行。这是因为重做日志有一个capacity变量，该值代表了最后的检查点不能超过这个阈值，如果超过则必须将缓冲池中脏页列表中的部分脏数据写回磁盘，这时会导致用户线程的阻塞

重做日志文件与二进制日志文件的区别

重做日志文件与二进制日志都是记录事务的日志，两者的区别如下：

首先，二进制日志会记录所有与MySQL数据库有关的日志记录，包括InnoDB、MyISAM、Heap等其他存储引擎的日志。而InnoDB存储引擎的重做日志只记录与该存储引擎本身的事务日志

其次，记录的内容不同，无论用户将二进制日志文件记录的格式设为STATEMENT、ROW还是MIXED，其记录的都是关于一个事务的具体操作内容，即该日志是逻辑日志。而InnoDB存储引擎的重做日志文件记录的是关于每个页（Page）的更改的物理情况

此外，写入的时间也不同，二进制日志文件仅在事务提交前进行提交，即只写磁盘一次，不论这是该事务多大。而在事务进行的过程中，却不断有重做日志条目被写入到重做日志文件中

重做日志条目结构

在InnoDB中，对于各种不同的操作有着不同的重做日志格式

到InnoDB 1.2.x版本为止，总共定义了51种重做日志类型。虽然各种重做日志的类型不同，但是它们有着基本的格式。下表显示了重做日志条目的结构：

redo_log_type：占用1字节，表示重做日志的类型

space：表示表空间的ID，但采用压缩的方式，因此占用的空间可能小于4字节

page_no：表示页的偏移量，同样采用压缩的方式

redo_log_body：表示每个重做日志的数据部分，恢复时需要调用相应的函数进行解析

重做日志的写入过程

在前面几篇文章中我们已经提到，写入重做日志文件的操作不是直接写，而是先写入一个重做日志缓冲（redo log buffer）中，然后按照一定的条件顺序地写入日志文件

下图很好地诠释了重做日志的写入过程：

从重做日志缓冲往磁盘写入时，是按512个字节，也就是一个扇区的大小进行写入。因为扇区是写入的最小单位，因此可以保证写入必定是成功的，因此在重做日志的写入过程中不需要有doublewrite

innodb_flush_log_at_trx_commit参数

前面提到过从日志缓冲中写入磁盘上的重做日志文件是按一定条件进行的，这些条件如下：

一个是前面在介绍“Master Thread”的文章中提到的，在主线程中每秒会将重做日志缓冲写入磁盘的重做日志文件中，不论事务是否已经提交

另一个触发写磁盘的过程是由innodb_flush_log_trx_commit参数控制的，表示在提交（commit）操作时，处理重做日志的方式

该参数的取值如下：

0：当提交事务时，并不将事务的重做日志写入磁盘上的日志文件，而是等待主线程每秒的刷新

1（默认值）：在执行commit时将重做日志缓冲同步写到磁盘，即即伴有fsync的调用

2：表示将重做日志异步写到磁盘，即写到文件系统的缓存中
show variables like 'innodb_flush_log_at_trx_commit'\G;
因此不能完全保证在执行commit时肯定会写入重做日志文件，只是有这个动作(commit)发生

因此为了保证实物的ACID中的持久性，必须将innodb_flush_log_trx_commit设置为1，也就是每当有事务提交时，就必须确保事务都已经写入重做日志文件。那么当数据库因为意外发生宕机时，可以通过重做日志文件恢复，并保证可以恢复已经提交的事务。而将重做日志文件设置为0或2，都有可能发生恢复时部分事务的丢失。不同之处在于，设置为2时，当MySQL数据库发生宕机而操作系统及服务器并没有发生宕机时，由于此时未写入磁盘的事务日志保存在文件系统缓存中，当恢复时同样能保证数据不丢失