Mysql的事务具有四个特性：原子性、一致性、隔离性、持久性。那么事务的四种特性分别是靠什么机制实现的呢？

• 事务的隔离性由锁机制来保证

• 事务的原子性、一致性、持久性则由redo log和Undo log来保证。
  - redo log是重做日志，提供再写入操作，恢复提交事务修改的页操纵，用来保证事务的持久性。
  - undo log是回滚日志，回滚记录到某个特定的版本，保证事务的原子性和一致性。

• redo log：是存储引擎(innodb)生成的日志，记录的是物理级别上的页修改操作，比如页号XXX、偏移量yyy写入了‘zzz’数据。主要是为了保证数据的可靠性。

• undo log:是存储引擎(innodb)生成的日志，记录的是逻辑操作日志。比如对某一行进行了insert语句操作，那么undo log就会记录与之相反的delete操作。主要用于事务的回滚(undo log记录的是每个修改操作的逆操作)和一致性非锁定读(undo log回滚记录到某个特定的版本—MVCC，多版本并发控制)。

1. redo log

InnoDB引擎是以页为基本单位来管理存储空间的。在真正访问页面之前，需要把磁盘上的页读取到内存的buffer pool中之后才能访问数据。所有的更新都必须先更新buffer pool中的数据，buffer pool中被更新过的页被称之为脏页(dirty page)，然后buffer pool中的脏页会以一定的频率被刷到磁盘中(check point机制)，通过缓冲池(buffer pool)来优化cpu和磁盘之间的速度鸿沟，保证整体的性能不会下降太快。

1.1 为什么需要redo日志？

一方面，缓冲池可以帮助我们消除cpu和磁盘之间的鸿沟，checkpoint机制可以保证数据的最终落盘。然后由于checkpoint不是每次变更都触发的，而是由master线程隔一段时间去同步的。所以最坏的情况是，数据更新到了缓冲池，但是还未来得及刷盘到磁盘中，数据库服务器就宕机了，那么这段数据就是丢失的，无法恢复了。
另一方面，事务包含持久性的特性，就是说对于一个已经提交的事务，即使事务提交后数据库发生崩溃，这个事务对于数据所做的更改也需要保持下来。
redo log就是为了解决这种场景，具体操作就是在内存中修改数据的时候，把这些操作也用日志的形式记录下来。比如某个事物的操作是将系统表空间中第10页中偏移量为100的数据的值由2改为1，那么在修改内存记录的时候，也会在redo log中记录：将系统表空间中第10页中偏移量为100的数据的值由2改为1。
InnoDB引擎采用WAL(write-ahead logging)技术，这种技术的思想就是先写日志再写磁盘，只有日志写入成功，才算事务提交成功。当发生数据库宕机，且存在buffer pool中的某个页数据已经修改，但是未来得及刷盘时，可以通过redo log来完成数据的恢复。通过这来保证事务ACID的D(持久性)，这就是redo log的作用。

1.2 redo log的好处、特点

1.好处

• redo log降低了刷盘频率
• redo log占用的空间非常小：存储表空间id，页号，偏移量以及需要更新的值，所需的存储空间是很小的，刷盘快。

2.特点

• redo log是顺序写入磁盘的：在执行事务的过程中，每执行一条语句，就可能产生若干条redo log，这些redo log是按产生的顺序写入磁盘的，也就是顺序IO，速度比较快。
• 事务执行过中，redo log不断记录：redo log和bin log的区别是，redo log是存储引擎层产生的，而bin log是数据库产生的。假设一个事物对某张表做10w行的记录插入，在这个过程中，会不断地往redo log进行顺序记录，而bin log不会记录，直到事务提交，才会一次性写入bin log文件中。

1.3 redo log的组成

redo log可以简单的划分为两部分：

• 重做日志的缓冲(redo log buffer)，保存在内存中，是易失的。在服务器启动的时候，就会向操作系统申请一大片被称为redo log buffer的连续内存空间，翻译成中文就是redo日志缓冲区。这片内存空间被划分成若干个连续的redo log block，一个redo log block占512字节大小。
  
  redo log buffer大小默认16M。
  
  重做日志文件(redo log file)保存在磁盘中，是持久的。

1.4 redo log的整体流程

1.先将要修改的数据行所在的数据页读取到内存中并修改内存中的数据页中的对应记录
2.在redo log buffer中新增对应的redo log，其中redo log记录的是对应表空间的对应页的指定偏移量的数据修改后的值
3.在事务commit的时候，将redo log buffer中新增的redo log以顺序IO的方式追加到磁盘的redo log file中
4.将buffer pool的脏页数据刷回磁盘

1.5 redo log的刷盘策略

redo log的写入并不是直接写入到磁盘的，而是先写到内存中的redo log buffer，然后一定的频率刷到磁盘的redo log file中。这个频率就是redo log的刷盘策略。

1.6 写入redo log buffer的过程

补充概念：Mini-transaction，简称mtr。比如向某个索引的B+树插入一条记录的过程就是一个Mini-transaction。一个所谓的mtr可能包括一组redo log日志，在进行崩溃恢复时，一组redo log作为不可分割的一部分。
一个事物可能包含若干个SQL语句，每个SQL语句其实是由若干个mtr组成，每一个mtr又可以包含若干个redo log日志。

1.6.1 redo log写入log buffer

向log buffer中写入redo log是顺序的，也就是先往前面的block中写，当该block写完后，再往后面的block写，InnoDB维护了一个buf_free变量，其中记录当下应该写入redo log的位置。

2.Undo log

redo log是事务持久性的保证，Undo log则是事务原子性的保证。在事务中更新数据的前置操作其实是先写入对应的undo log。

2.1 如何理解undo log

事务的原子性就是一组操作要么全部成功，要么全部失败。但是事务有时候会遇到一些情况导致一组操作中部分操作成功就中断了。遇到这种情况就需要将数据恢复到修改之前的状态，这就称之为回滚。
每当我们需要对一条记录进行改动(此处的改动包括 insert/update/delete)的时候，都需要留一手，记录改动之前的状态。比如：

• 当你插入一条记录的时候，就需要把这条记录的主键值记录下来，回滚的时候根据主键删除这条记录就行了。(每个insert在undo log会记录对应的delete)
• 当你删除一条记录的时候，就需要把这条记录的信息完整记录下来，回滚的时候再把这条记录进行插入就行了。(每个delete在undo log会记录对应的insert)
• 当你update一条记录的时候，也会把update之前的旧值记录下来，回滚的时候再把对应的值改为旧值就行了。(每个update会在undo log记录一个相反的update)

MySQL将这些为了回滚需要而记录的日志称之为undo log。因为select不会产生数据修改，所以select不会产生undo log。

2.2 Undo log的作用

• 作用1：回滚数据
• 作用2：MVCC

2.3 Undo log的存储结构

2.3.1 回滚段与undo页

InnoDB对于undo log采用回滚段的的方式进行管理，每个回滚段记录了1024个undo log segment，而在每个undo log segment中进行undo页的申请。