mysql 事务重做日志(redo log)与回滚日志(undo log)

查看事务日志：
show engine innodb status;
show engine innodb status\G;

查看日志文件设置状态：
show variables like 'innodb_%';

innodb_log_files_in_group:DB 中设置几组事务日志，默认是2；
innodb_log_group_home_dir 事务日志存放目录，不设置；
ib_logfile0… 存放在数据文件目录下 InnoDB 存储引擎可将所有数据存放于 ibdata* 的共享表空间，也可将每张表存放于独立的 .ibd 文件的独立表空间；

注意：在 MySQL 中对于数据来说，最为重要的是日志文件

redo log => ib_logfile0…

undo log => ibdata

重做日志

持久化

事务被提交，数据一定会被写入到数据库中并持久存储起来，通常来说当事务已经被提交之后，就无法再次回滚了。

重做日志实现持久化

与原子性一样，事务的持久性也是通过日志来实现的，MySQL 使用重做日志（ redo log ）实现事务的持久性，重做日志由两部分组成，一是内存中的重做日志缓冲区，因为重做日志缓冲区在内存中，所以它是易失的；另一个就是在磁盘上的重做日志文件，它是持久的。

当我们在一个事务中尝试对数据进行写时，它会先将数据从磁盘读入内存，并更新内存中缓存的数据，然后生成一条重做日志并写入重做日志缓存，当事务真正提交时，MySQL 会将重做日志缓存中的内容刷新到重做日志文件，再将内存中的数据更新到磁盘上，图中的第4、5步就是在事务提交时执行的。

重做日志执行

在MySQL中事务执行 commit 提交了之后，但是服务器宕机了，数据还没有写入磁盘，在MySQL重启服务之后会重新执行这个重做日志写入数据。

回滚日志

原子性

通俗的解释就是：一条绳子上的蚂蚱。
专业性的解释是：事务一系列的操作，要么全部执行，要么都不执行。

回滚日志实现原子性

想要保证事务的原子性，就需要在异常发生时，对已经执行的操作进行回滚，而在 MySQL 中，恢复机制是通过回滚日志（ undo log ）实现的，所有事务进行的修改都会先记录到这个回滚日志中，然后再对数据库中的对应行进行写入。注意：系统发生崩溃、数据库进程直接被杀死后，当用户再次启动数据库进程时，还能够立刻通过查询回滚日志将之前未完成的事务进行回滚，这也就需要回滚日志必须先于数据持久化到磁盘上，是我们需要先写日志后写数据库的主要原因。在日志文件中：在事务中使用的每一条 insert into 都对应了一条 delete ，每一条 update 也对应一条相反的 update 语句。

回滚日志执行

1. 手动执行回滚命令时会执行。
2. 如果程序在事务执行之后，提交命令执行之前出现了异常，在下次 MySQL 服务重启的时候会执行。

测试：在事务提交前停止mysql服务

然后我们停止MySQL服务：

停止成功；然后再开启 MySQL 服务：

启动成功，然后查询一下数据：

没有查询到新增的数据；数据已经丢失了，需要执行了commit之后数据才不会丢失。

重做日志与回滚日志总结

到现在为止我们了解了 MySQL 中的两种日志，回滚日志（ undo log ）和重做日志（ redo log ）；在数据库系统中，事务的原子性和持久性是由事务日志（ transaction log ）保证的，在实现时也就是上面提到的两种日志；欠着用于对事务的影响进行撤销，后者在错误处理时对已经提交的事务进行重做，它们能保证两点：

1. 发生错误或者需要回滚的事务能够成功回滚（原子性）。
2. 在事务提交后，数据没来得及写入磁盘就宕机时，在下次重新启动后能够成功恢复数据（持久性）。

在数据库中，这两种日志经常都是一起工作的，我们可以将他们整体看作一条事务日志，其中包含了事务的ID、修改的行元素以及修改前后的值。