我们知道mysql数据库相关的一些文件，可以分为 MySQL数据库文件 以及 各存储引擎相关的文件 。与MySQL数据库有关的文件中，错误文件和二进制日志文件非常重要。当MySQL数据库发生任何错误时，DBA首先就应该去查看错误文件，从文件提示的内容中找出问题所在。当然，错误文件不仅记录了错误内容，也记录了警告的信息，通过一些警告也有助于DBA对于数据库和存储引擎进行优化。接下来，我们介绍与InnoDB存储引擎密切相关的文件，这些文件包括 表空间文件 、 重做日志文件 。
表空间文件InnoDB采用将存储的数据按表空间（tablespace）进行存放的设计。在默认配置下会有一个初始大小为10MB，名为 ibdata1 的文件。该文件就是默认的表空间文件（tablespace file），用户可以通过参数 innodb_data_file_path 对其进行设置，格式如下：
SQL
innodb_data_file_path=datafile_spec1[;datafile_spec2]...用户可以通过多个文件组成一个表空间，同时制定文件的属性，如：
SQL
[mysqld] innodb_data_file_path = /db/ibdata1:2000M;/dr2/db/ibdata2:2000M:autoextend这里将 /db/ibdata1 和 /dr2/db/ibdata2 两个文件用来组成表空间。若这两个文件位于不同的磁盘上，磁盘的负载可能被平均，因此可以提高数据库的整体性能。同时，两个文件的文件名后都跟了属性，表示文件 ibdata1 的大小为2000MB，文件 ibdata2 的大小为2000MB，如果用完了这2000MB，该文件可以自动扩增（ autoextend ）。
设置 innodb_data_file_path 参数后，所有基于InnoDB存储引擎的表的数据都会记录到该共享表空间中。若设置了参数 innodb_file_per_table ，则用户可以将每个基于InnoDB存储引擎的表产生一个独立的表空间。独立表空间的命名规则为： 表名.ibd 。通过这样的方式，用户不用将所有数据都存放于默认的表空间中。下面这台MySQL数据库服务器设置了 innodb_file_per_table ，故可以观察到：
SQL
tqdb@localhost.[tqdb] 17:49:44> show variables like 'innodb_file_per_table'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | innodb_file_per_table | ON | +-----------------------+-------+ 1 row in set (0.00 sec) tqdb@localhost.[tqdb] 18:03:15> system ls -lh /MySQL_DATA/tqdb/ total 399M ... 略 ... -rw-rw---- 1 mysql mysql 8.4K Nov 26 17:07 t1.frm -rw-rw---- 1 mysql mysql 112K May 17 13:40 t1.ibd -rw-rw---- 1 mysql mysql 432 May 16 14:58 t1_view1.frm -rw-rw---- 1 mysql mysql 432 May 16 14:48 t1_view.frm -rw-rw---- 1 mysql mysql 8.5K Mar 4 17:21 t2.frm -rw-rw---- 1 mysql mysql 112K Apr 18 18:23 t2.ibd -rw-rw---- 1 mysql mysql 8.4K Mar 15 15:04 t3.frm -rw-rw---- 1 mysql mysql 96K Mar 15 15:38 t3.ibd -rw-rw---- 1 mysql mysql 8.4K Mar 30 15:51 t4.frm -rw-rw---- 1 mysql mysql 96K Mar 30 15:51 t4.ibd -rw-rw---- 1 mysql mysql 8.4K Mar 30 15:49 t5.frm -rw-rw---- 1 mysql mysql 96K Mar 30 15:50 t5.ibd -rw-rw---- 1 mysql mysql 8.4K Apr 8 15:05 t6.frm -rw-rw---- 1 mysql mysql 96K Apr 8 15:07 t6.ibd -rw-rw---- 1 mysql mysql 8.4K Apr 18 18:45 t7.frm -rw-rw---- 1 mysql mysql 112K Apr 18 18:47 t7.ibd -rw-rw---- 1 mysql mysql 8.5K Apr 19 15:15 t8.frm -rw-rw---- 1 mysql mysql 128K Apr 19 15:15 t8.ibd -rw-rw---- 1 mysql mysql 8.8K May 11 19:06 test1.frm -rw-rw---- 1 mysql mysql 92M May 11 19:12 test1.ibd -rw-rw---- 1 mysql mysql 8.8K May 11 19:07 test2.frm -rw-rw---- 1 mysql mysql 92M May 11 19:20 test2.ibd -rw-rw---- 1 mysql mysql 8.4K Nov 26 17:03 t.frm -rw-rw---- 1 mysql mysql 96K May 12 16:00 t.ibd ... 略 ...表 t、t1~t8、test1、test2 都是基于InnoDB存储的表，由于设置参数 innodb_file_per_table=ON ，因此产生了 单独的.ibd独立表空间文件 。 需要注意的是，这些单独的表空间文件仅存储该表的数据、索引和插入缓冲BITMAP等信息，其余信息还是存放在默认的表空间中 。下图，显示了InnoDB存储引擎对于文件的存储方式：
重做日志文件
在默认情况下，在InnoDB存储引擎的数据目录下会有两个名为 ib_logfile0 和 ib_logfile1 的文件。在MySQL官方手册中将其称为InnoDB存储引擎的日志文件，不过更准确的定义应该是重做日志文件（ redo log file ）。为什么强调是重做日志文件呢？因为重做日志文件对于InnoDB存储引擎至关重要，它们记录了对于InnoDB存储引擎的事务日志。
当实例或介质失败（ media failure ）时，重做日志文件就能派上用场。例如，数据库由于所在主机掉电导致实例失败，InnoDB存储引擎会使用重做日志恢复到掉电前的时刻，以此来保证数据的完整性。
每个InnoDB存储引擎 至少有1个重做日志文件组 （ group ）， 每个文件组下至少2个重做日志文件 ，如默认的 ib_logfile0 和 ib_logfile1 。为了得到更高的可靠性，用户可以设置多个镜像日志组（ mirrored log groups ），将不同的文件组放在不同的磁盘上，以此提高重做日志的高可用性。 在日志组中的每个重做日志文件的大小一致，并以循环写入的方式运行 。InnoDB存储引擎先写重做日志文件0，当达到文件的最后时，会切换至重做日志文件1，再当重做日志文件1也被写满时，会再切换到重做日志文件0中。下图，显示了一个拥有3个重做日志文件的重做日志文件组。
下列参数影响着重做日志文件的属性：
innodb_log_file_size innodb_log_files_in_group innodb_mirrored_log_groups innodb_log_group_home_dir参数 innodb_log_file_size 指定每个重做日志文件的大小。在InnoDB 1.2.x 版本之前，重做日志文件总的大小不得大于等于4GB，而 1.2.x 版本将该限制扩大为了512GB。
参数 innodb_log_files_in_group 指定了日志文件组中重做日志文件的数量，默认为2。参数 innodb_mirrored_log_groups 指定了日志镜像文件组的数量，默认为1，表示只有一个日志文件组，没有镜像。若磁盘本身已经做了高可用的方案，如磁盘阵列，那么可以不启重做日志镜像的功能。最后，参数 innodb_log_group_home_dir 指定了日志文件组所在的路径，默认为 ./ ，表示在MySQL数据库的数据目录下。以下显示了一个关于重做日志组的配置：
SQL
tqdb@localhost.[tqdb] 18:28:28> show variables like 'innodb%log%'; +----------------------------------+-----------+ | Variable_name | Value | +----------------------------------+-----------+ | innodb_api_enable_binlog | OFF | | innodb_flush_log_at_timeout | 1 | | innodb_flush_log_at_trx_commit | 1 | | innodb_locks_unsafe_for_binlog | OFF | | innodb_log_buffer_size | 8388608 | | innodb_log_compressed_pages | ON | | innodb_log_file_size | 268435456 | | innodb_log_files_in_group | 3 | | innodb_log_group_home_dir | ./ | | innodb_mirrored_log_groups | 1 | | innodb_online_alter_log_max_size | 134217728 | | innodb_undo_logs | 128 | +----------------------------------+-----------+ 12 rows in set (0.00 sec)重做日志文件的大小设置对于InnoDB存储引擎的性能有着非常大的影响。一方面重做日志文件不能设置得太大，如果设置得很大，在恢复时可能需要很长的时间；另一方面又不能设置得太小了，否则可能导致一个事务的日志需要多次切换重做日志文件。此外，重做日志文件太小会导致频繁地发生 async checkpoint ，导致性能的抖动。例如：用户可能会在错误日志中看到如下警告信息：
SQL
090924 11:39:44 InnoDB: ERROR: the age of the last checkpoint is 9433712, InnoDB: which exceeds the log group capacity 9433498. InnoDB: If you are using big BLOB or TEXT rows, you must set the InnoDB: combined size of log files at least 10 times bigger than the InnoDB: largest such row. 090924 11:40:00 InnoDB: ERROR: the age of the last checkpoint is 9433823, InnoDB: which exceeds the log group capacity 9433498. InnoDB: If you are using big BLOB or TEXT rows, you must set the InnoDB: combined size of log files at least 10 times bigger than the InnoDB: largest such row. 090924 11:40:16 InnoDB: ERROR: the age of the last checkpoint is 9433645, InnoDB: which exceeds the log group capacity 9433498. InnoDB: If you are using big BLOB or TEXT rows, you must set the InnoDB: combined size of log files at least 10 times bigger than the InnoDB: largest such row.从上面错误集中在 InnoDB: ERROR: the age of the last checkpoint is 9433645, InnoDB: which exceeds the log group capacity 9433498. 。这是因为重做日志有一个 capacity 变量，该值代表了最后的检查点不能超过这个阈值，如果超过则必须将缓冲池（ innodb buffer pool ）中脏页列表（ flush list ）中的部分脏数据页写回磁盘，这时会导致用户乡线程的阻塞。
也许有人会问，既然同是记录事务日志，那重做日志和二进制日志有什么区别？
首先，二进制日志记录所有与MySQL数据库相关的日志记录，包括 InnoDB 、 MyISAM 、 Heap 等其他存储引擎的日志。而InnoDB存储引擎的重做日志只记录有关该存储引擎本身的事务日志。 其次，记录的内容不同，无论用户将二进制日志文件记录格式设置为 STATEMENT 、还是 ROW ，又或者是 MIXED ，其记录的都是关于一个事务的具体操作内容，即该日志是逻辑日志。而InnoDB存储引擎的重做日志文件记录的是关于每个页（ page ）的更改的物理情况。 此外，写入时间也不同，二进制日志文件仅在事务提交前进行提交，即只写磁盘一次，不论这时该事务多大。而在事务进行的过程中，却不断有重做日志条目（ redo entry ）被写入到重做日志文件中。在InnoDB存储引擎中，对于各种不同的操作有着不同的重做日志格式。到InnoDB 1.2.x 版本为止，总共定义了51种重做日志类型。虽然各种重做日志的类型不同，但是它们有着基本的格式。下图，显示了重做日志条目的结构：
从上图，可以看到重做日志条目是由4个部分组成：
redo_log_type 占用1字节，表示重做日志的类型。 space 表示表空间的ID，但采用压缩的方式，因此占用的空间可能小于4字节。 page_no 表示页的偏移量，同样采用压缩的方式。 redo_log_body 表示每个重做日志的数据部分，恢复时需要调用相应的函数进行解析。写入重做日志的操作不是直接写，而是先写入一个重做日志缓冲（ redo log buffer ）中，然后按照一定的条件顺序地写入日志文件。下图，很好地诠释了重做日志的写入过程。
从重做日志缓冲往磁盘写入时，是按512个字节，也就是一个扇区的大小进行写入。因为扇区是写入的最小单位，因此可以保证写入必定是成功的。因此在重做日志的写入过程中不需要有 doublewrite 。
前面提到了从日志缓冲写入磁盘上的重做日志文件是按一定条件进行的，那这些条件有哪些呢？我们知道在主线程（ master thread ）中 每秒 会将重做日志缓冲写入磁盘的重做日志文件中，不论事务是否已经提交。另一个触发写磁盘的过程是由参数 innodb_flush_log_at_trx_commit 控制，表示在提交（ commit ）操作时，处理重做日志的方式。
参数 innodb_flush_log_at_trx_commit 的有效值有 0、1、2 。0代表当提交事务时，并不将事务的重做日志写入磁盘上的日志文件，而是等待主线程每秒的刷新。1和2不同的地方在于：1表示在执行commit时将重做日志缓冲同步写的磁盘，即伴有 fsync 的调用。2表示将重做日志异步写到磁盘，即写到文件系统的缓存中。因此不能完全保证在执行commit时肯定会写入重做日志文件，只是有这个动作发生。
因此 为了保证事务的ACID中的持久性，必须将innodb_flush_log_at_trx_commit设置为1 ，也就是每当有事务提交时，就必须确保事务都已经写入重做日志文件。那么当数据库因为意外发生宕机时，可以通过重做日志文件恢复，并保证可以恢复已经提交的事务。而将重做日志文件设置为0或者2，都有可能发生恢复时部分事务的丢失。不同之处在于，设置为2时，当MySQL数据库发生宕机而操作系统及服务器并没有发生宕机时，由于此时未写入磁盘的事务日志保存在文件系统缓存中，当恢复时同样能保证数据不丢失。
-- The End --