MySQL事务日志

事务的四种特性：原子性、一致性、隔离性和持久性。

事务的隔离性由锁机制实现。

事务的原子性、一致性和持久性由事务的redo日志和undo日志来保证。

redo log：重做日志，提供再写入操作，恢复提交事务修改过的页操作，用来保证事务的持久性

undo log：回滚日志，回滚行记录到某个特定版本，用来保证事务的原子性、一致性

redo和undo都可以视为一种恢复操作。

redo log：记录的是“物理级别”上的页修改操作，物理磁盘比如页号xxx、偏移量yyy写入了“zzz”数据，主要是为了保证数据的可靠性

undo log：记录的是“逻辑操作”日志，比如对某一行数据进行了INSERT语句操作，那么undo log就记录一条与之相反的DELETE操作。主要用于事务的回滚(undo log记录的是每个修改操作的逆操作)和一致性非锁定读

一、redo日志

InnoDB存储引擎是以页为单位来管理存储空间的。在真正访问页面之前，需要把在磁盘上的页缓存到内存中的Buffer Pool之后才可以访问。所有的变更都必须先更新缓冲池中的数据，然后缓冲池中的脏页会以一定的频率被刷入磁盘。通过缓冲池来优化CPU和磁盘之间的鸿沟，这样可以保证整体的性能不会下降太快。

让已提交的事务对数据库中的数据所有的修改永久生效，即使后来系统崩溃，在重启后也能把这种修改恢复出来。所以没必要在每次事务提交时就把该事务在内存中修改过的全部页面刷新到磁盘，只需要把修改了哪些东西记录一下。

先写日志(redo log)，再写磁盘，只有日志写入成功，才算事务提交成功，当发生宕机且数据未刷到磁盘的时候，可以通过redo log来恢复，保证事务的持久性。

优点：降低了刷盘频率，占用空间小。

特点：redo日志是顺序写入磁盘、事务执行过程中，redo log不断记录。

二、undo日志

redo log是事务持久性的保证，undo log是事务原子性的保证。在事务中更新数据的前置操作其实是要写入一个undo log。

事务需要保证原子性，也就是事务中的操作要么全部完成、要么什么也不做。但有时候事务执行到一半会出现一些意外如断电、操作系统出现错误或程序员需要手动输入ROLLBACK语句结束当前事务的执行。这时需要把数据改回原来的样子，这个过程称之为回滚。

undo log：

插入——记录主键，根据主键删除

删除——记录内容，插入

修改——记录旧值，修改回去

查询操作并不会修改任何记录，不需要记录相应的undo日志。

 

undo log：对事务进行回滚，只是将数据库逻辑地恢复到原来的样子

redo log：对事务进行恢复，记录的是数据页的物理变化，undo log不是redo log的逆过程。