파일은 앞에서 설명한 MySQL 데이터베이스 파일 자체 및 스토리지 엔진에 관련이 없습니다. 이 문서에서는 관련된 고유 한 파일 스토리지 엔진을 . 이 문서는 밀접하게 InnoDB의 관련 파일이이 파일이 포함 설명 리두 로그 파일을 테이블 공간 파일

첫째, 테이블 공간 파일

기능 : InnoDB의 사용은 저장 테이블 공간 (TABLESPACE)에 의해 저장된 데이터 설계를
에서 초기가 10MB 크기, idbata1 파일 이름 (아래 참조)해야합니다 기본 구성 파일은 기본 파일 테이블입니다

innodb_data_file_path에 매개 변수

이 매개 변수 를 지정 InnoDB의 테이블 스페이스 파일을 사용합니다 . 이 파라미터를 설정 한 후, 이노 모든 데이터가 공유 공간 테이블에 기록 될 스토리지 엔진의 테이블에 기초

예를 들어 파일 공간을 보여주는 다음 표는 기본적 InnoDB에 의해 사용
show variables like 'innodb_data_file_path'\G;
매개 변수의 형식은 다음과 같습니다

당신이 할 경우 테이블 공간에 여러 파일을 전달하고 등록 정보 파일을 개발하기 위해, 다음과 같은 형식의 케이스를 사용할 수 있습니다 :

여기에 / DB /을 ibdata1 및 / DR2 / DB / ibdata2 테이블 스페이스를 형성하는데 사용되는 두 개의 파일 . 이 두 파일은 다른 디스크에있는 경우, 디스크로드 평균 수 있습니다, 할 수 있는 데이터베이스의 전반적인 성능을 향상

같은 시간에 파일 이름도 파일 크기 속성 뒤에 가서 : 이 2,000메가바이트이 부족하면을 ibdata1의 크기가 2천메가바이트, 2,000메가바이트의 ibdata2 크기를 나타냅니다, 파일이 자동으로 증가

innodb_file_per_table 매개 변수

이 변수가 설정되면, 사용자 수 는 각각 InnoDB의 스토리지 엔진에 기초하여 테이블 생성 독립된 테이블을. 이러한 방법으로, 사용자는 모든 데이터가 기본 테이블 공간에 저장되어 있지 않습니다 . 이 매개 변수는 별도의 테이블 스페이스 파일을 사용하지 않는, 기본적으로 꺼져
show variables like 'innodb_file_per_table'\G;
별도의 테이블 스페이스 의 이름 지정 규칙은 테이블 이름있는 .ibd

이러한 별도의 테이블 스페이스 파일 참고 만 저장 테이블의 데이터, 인덱스, 삽입 버퍼 비트 맵 정보가, 나머지 정보는 기본 테이블 공간에 저장됩니다. 다음 그림은 InnoDB 스토리지 엔진 파일의 저장을 보여줍니다

이 MySQL 데이터베이스 서버 설정 아래이 매개 변수를 관찰 할 수있다 :

표 프로필, T1은 T2는 이노에 기억 된 테이블에 기초

파라미터 innodb_file_per_table = ON 사용되므로 별도의 독립된 테이블 파일 생성있는 .ibd

둘째, 리두 로그 파일 (리두 로그)

리두 로그 파일 정보 :
- 기본적으로 InnoDB 스토리지 엔진에서 데이터 디렉토리는이 ib_logfile0 및 ib_logfile1라는 이름이 개 파일을 . MySQL의 InnoDB의 스토리지 엔진의 로그 파일에 대한 공식 설명서에 말하고 있지만,보다 정확한 정의해야 로그 파일 (리두 로그 파일) 다시 실행
- 왜 리두 로그 파일을 강조? InnoDB 스토리지 엔진에 대한 리두 로그 파일이 필수적이기 때문에, 그들은 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数据库发生宕机而操作系统及服务器并没有发生宕机时，由于此时未写入磁盘的事务日志保存在文件系统缓存中，当恢复时同样能保证数据不丢失