事务的隔离性是通过锁实现，而事务的原子性、和持久性则是通过事务日志实现。在MySQL中，事务日志分为两类，一个是Redo Log，也叫重做日志，另一个是Undo Log，也叫回滚日志；其中Redo Log保证事务的持久性，Undo Log保证的是事务的原子性；

2.1 Redo Log

2.1.1 Redo Log与持久性

事务开启后，执行的所有的操作都是记录在事务日志中，这部分数据并没有写入磁盘表，需要把当前事务提交，才会将事务日志记录的数据写入到磁盘表中。Redo Log是用于保证事务的ACID中的持久性的，关于什么是持久性我们必须弄清楚这一点。

事务的持久性：事务提交成功后，数据被保存到磁盘表中，即使发生系统崩溃、断电或其他故障，只要表、磁盘等软硬件设备不被损坏，那么数据将永久保持在磁盘中。

这里存在一个疑问，事务都提交成功了，系统发生崩溃、断电或其他故障不是本就不会影响到磁盘表中的数据吗？当然前提是磁盘表中的数据没有损坏，那这个持久性到底保障的是什么呢？

需要注意：事务的持久性指的是事务一旦提交成功，才能保障后续的流程（崩溃、宕机等问题的处理）。可不是保证事务一定能提交成功。如果事务在提交过程中出现问题，这个问题包括事务运行过程中的问题（一般是客户端的代码问题），也包括MySQL服务器自身的问题（一般是执行commit命令时宕机、系统奔溃等）。但不管是客户端或者是MySQL服务器本身的问题导致的提交失败，MySQL都会将其标记为提交失败，客户端接收到MySQL响应的提交失败请求后可以做其他的补偿处理。

如果一个事务被标记为提交成功，那么数据能够正常写入磁盘表，并且不怕MySQL宕机、服务器崩溃等，如果一个事务被标记为失败，那么该出现的问题还是会出现的。那么也可以这么理解：如何让事务能够快速被标记为成功，或许才是是事务日志真正所要考虑的问题，毕竟能够快速标记为成功，那就少一份执行commit时MySQL宕机、服务器崩溃的风险。

2.1.2 Redo Log的工作原理

Redo日志也叫重做日志，在InnoDB存储引擎中使用。它记录了数据在内存中更改之后但还未持久化到磁盘表之前的信息。它的主要作用是在系统崩溃后能够重新执行（redo）那些已经提交但尚未写入磁盘的数据更改。如果在事务提交时，此时数据库崩溃或者宕机，那么当系统重启进行恢复时，就可以根据Redo Log中记录的日志，把数据库恢复到崩溃前的一个状态。因此Redo Log 是InnoDB实现事务持久性的强力保证。

Tips：Redo Log主要保障的是事务的持久性，即只要事务提交成功，那么数据就能够永久保存到数据库中，否则就属于提交失败，就应该进行事务回滚（根据Undo 日志回滚），客户端也可以做一些事务提交失败的代码流程。

Redo的运行流程：

首先在操作表时，会将表数据从磁盘（.idb）加载到内存缓冲池中（Buffer Pool），对表所有的操作都会记录一份到Redo Buffer日志（内存中的Redo日志）中，其根据一定的策略将数据刷新到Redo Log中（磁盘中的Redo日志）。在事务最终要提交时（执行了commit），如果数据库或系统突然宕机，那么当数据库或系统重启时，就可以根据Redo Log日志中的记录进行数据的恢复。

Redo Log的工作原理如图所示：

在提交事务时，为什么不直接将数据写入数据库表呢？而是要先写入Redo Log中呢？看似好像“多此一举”？其实不然。写入Redo Log的好处如下：

原因一：Redo Log的结构简单。

Redo Log 记录的是物理层面上的数据修改，因此Redo也叫物理日志。这些修改记录包含了数据页的物理地址（Page Number）和修改的具体内容（如页内数据的前后变化）。在系统重启时，InnoDB 会读取 Redo Log 文件，并根据其中的记录重做对数据页的修改。

Redo Log的日志格式：

正因为Redo Log中记录的数据结构简单，只记录一些物理地址以及一些变更状态等信息。因此数据先写入Redo Log要比直接写入到表快多了。其次，Redo Log作为“临时存储的数据区域”，当Redo Buffer中的数据已经到达一定大小后，Redo Buffer也会将这部分数据写入到Redo Log中，此时数据还未提交，但是已经写入到磁盘中了。

Tips：上面流程中这种先写日志，再写磁盘，只有日志写入成功，才算事务提交成功的技术思想在MySQL也叫做WAL技术 (Write-Ahead Logging日志先行)。

原因二：顺序IO性能远高于随机IO。

数据在MySQL中存储是以页为单位，事务中操作的数据可能遍布在不同的页中，如果直接写入到磁盘中对应的页中，是随机IO写入，效率低。

而Redo Log是通过往Redo Log日志中追加数据的方式，属于顺序IO，效率高。这样可能会影响Redo Log恢复数据时的性能，但可以保证在提交时期能够快速写入Redo Log日志记录本次事务的更改。

2.1.3 Redo Log的落盘策略

事务的日志是先写入到redo log buffer中的，并且这个过程是非常快的，那redo log buffer在什么时候会写入磁盘呢？

redo log buffer不是直接将日志内容刷盘到redo log file中，而是先刷入到操作系统的文件系统缓存（page cache）中去。最后，日志内容会从操作系统的文件系统缓存中刷到磁盘的日志文件中，至于什么时候触发这个动作，MySQL的innoDB引擎提供了3种策略可选。

Tips：Redo Log Buffer 刷新到 page cache 后，如果是MySQL宕机则问题不大，但是如果整个系统宕机数据将会丢失，因为数据都保存在操作系统的page cache中。不过这个过程很快，而且整个系统宕机概率相对MySQL会小很多。

InnoDB引擎提供了 innodb_flush_log_at_trx_commit 参数，该参数控制 commit提交事务时，如何将 redo log buffer中的日志刷新到 redo log file的3种策略，取值有0、1、2；默认为1。

mysql> select @@innodb_flush_log_at_trx_commit;
+----------------------------------+
| @@innodb_flush_log_at_trx_commit |
+----------------------------------+
|                                1 |
+----------------------------------+
1 row in set (0.00 sec)

0：代表每秒将Redo Buffer中的数据刷到OS buffer然后立即从OS buffer刷到Redo Log磁盘文件中。

为0时，后台线程每隔1秒进行一次重做日志的刷盘操作。在这种情况下，MySQL宕机最多丢失1s内的事务数据，这种方式效率最高，但是安全性最低。

1：代表每次提交事务都将Redo Buffer同步到OS Buffer然后立即从OS Buffer刷到Redo Log磁盘文件中（默认值）。

为1时，每次事务提交时都将进行同步, 执行主动刷盘操作。在这种情况下，MySQL宕机最多丢失1次事务的数据，安全性最高，效率偏低。

2：代表每次提交都将Redo Buffer中的数据刷到OS Buffer，然后再隔一秒从OS Buffer刷到Redo Log磁盘文件中。

为2时，只要事务提交成功，redo log buffer中的内容只写入文件系统缓存（pagecache）。在这种情况下，如果是MySQL宕机，最多丢失1次事务的数据，但是如果是操作系统宕机，则可能会丢失1s内的数据。安全性和效率折中。

测试不同的redo刷盘策略对性能的影响：

mysql> truncate userinfo;
Query OK, 0 rows affected (0.01 sec)

mysql> set global innodb_flush_log_at_trx_commit=0;
Query OK, 0 rows affected (0.00 sec)

mysql> call test_insert(10000);
Query OK, 1 row affected (0.42 sec)

mysql> truncate userinfo;
Query OK, 0 rows affected (0.01 sec)

mysql> set global innodb_flush_log_at_trx_commit=1;
Query OK, 0 rows affected (0.00 sec)

mysql> call test_insert(10000);
Query OK, 1 row affected (17.36 sec)

mysql> truncate userinfo;
Query OK, 0 rows affected (0.01 sec)

mysql> set global innodb_flush_log_at_trx_commit=2;
Query OK, 0 rows affected (0.00 sec)

mysql> call test_insert(10000);
Query OK, 1 row affected (0.46 sec)

mysql>

Redo Buffer 除了上面3种策略进行刷盘以外，还有另外一种特殊的场景：当redo log buffer占用的空间即将达到 innodb_log_buffer_size 一半的时候，后台线程会主动写盘。需要注意，由于这个事务并没有提交，所以这个写盘动作只是 write，而没有调用 fsync，也就是只留在了文件系统的 page cache。

2.1.4 Redo Log的系统参数

innodb_log_buffer_size：Redo Buffer的大小，默认16M
innodb_log_file_size：单个Redo Log事务日志文件的最大大小，默认48M
innodb_log_files_group：Redo Log日志文件的个数，默认2个
innodb_log_group_home_dir：Redo Log的存放路径；默认值为./代表当前MySQL的数据目录（Linux默认是/var/lib/mysql）
innodb_log_checksums：启用或禁用Relo log数据页的校验，默认开启。
innodb_log_compressed_pages：指定是否将重新压缩的页写入Redo Log，默认是开启状态