MySQL事务简述（二）

redo log称为重做日志，用来保证事务的原子性和持久性。

redo log通常是无力日志，记录的是页的物理修改操作。

其包含两部分：一是内存中的重做日志缓冲（redo log buffer）；二是重做日志文件（redo log file）。

在InnoDB存储引擎中，通过FLC（Force Log at Commit）机制实现事务的持久性。

即当事务提交时，必须先将素有的日志写入到重做日志文件进行吃就好，待事务的Commit操作完成才算完成。

redo log基本上都是顺序写的，在数据库运行时不需要多redo log的文件进行读取操作。

这里有个细节，重做日志日文件打开时没有使用O_DIRECT选项，因此重做日志缓冲先写入文件系统缓存。为了确保充足哦日志写入磁盘，必须进行一次fsync操作。

由此可见，数据库性能受fsync操作磁盘性能的瓶颈的影响。

可以通过手工设置，让数据库等待一个时间周期在执行fsync操作。将尽可能多的fsync磁盘操作合并在一起操作，这样可以明显提升性能。但是这违反了持久性原则，当发生数据库宕机时，会丢失最后一段时间的事务。

参数innodb_flush_log_at_trx_commit就是来控制充足哦日志拴心到磁盘的策略的。

默认值1，表示事务提交时必须调用一次fsync。

0，表示事务提交时不进行写入重做日志操作。这个操作将仅在master thread中进行，在master thread中每1秒会进行一次重做日志文件的fsync操作。

2，表示事务提交时，将重做日志写入文件系统的缓存中，不进行fsync操作。当数据库发生宕机时，不会导致事务的丢失。但操作系统宕机时，会丢失未从文件系统缓存刷新到重做日志文件的那部分事务。

在较大数据操作情况下，设置未0时性能最好，2次之，1最差。0和1之间的性能可能相差10倍。

在InnoDB存储引擎中，重做日志都是以512自己进行存储的。重做日志缓冲和重做日志文件都是这样。称之为重做日志块，每块大小512字节。

重做日志块可以存储492字节内容。另外的空间头信息占用12字节，尾信息占用8自己。

重做日志允许有多个重做日志文件，我们称为重做日志组。组中的每一个日志文件大小时享用的。InnoDB存储引擎1.2版本以前，重做日志文件的总大小瑶小雨4GB，从1.2版以后限制提高为512G。

重做日志缓冲刷新到重做日志文件，由以下3个规则控制：

1.事务提交时

2.log buffer中有一半的内存空间已经被使用时

3.log checkpoint时

重做日志组中第一个日志文件，其前2K部分不保存重做日志信息。它分为4块，分别保存log file header，checkpoint1，空，checkpoint2.

其余的重做日志文件则是保留文件签2K空间不用。

说到checkpoint，就不得不提到LSN（Log Sequence Number），日志序列号。

其占用8字节，单调递增。其表示：

1.重做日志写入的总量

2.checkpoint的位置

3.页的版本

当MySQL重启的时候，无论是否是正常关闭，都会尝试进行恢复操作。重做日志就是在这个阶段发挥作用。因为是物理日志，所以速度要比二进制日志快很多。checkpoint表示已经刷新到磁盘页上的LSN，因此恢复过程仅需从checkpoint开始的部分开始。