mysql学习笔记-MySql事务日志

1、redo日志

1.1、为什么需要REDO日志？

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

久性。数据库宕机，保证数据不丢失。

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

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

1.2、REDO日志的好处、特点

好处：

redo日志降低了刷盘频率

redo日志占用的空间非常小

特点

redo日志是顺序写入磁盘的

事务执行过程中，redo log不断记录

1.3、redo的组成

重做日志的缓冲 (redo log buffer) ，保存在内存中，是易失的。

重做日志文件 (redo log file) ，保存在硬盘中，是持久的。

1.4、redo整体流程

第1步:先将原始数据从磁盘中读入内存中来，修改数据的内存拷贝第

2步:生成一条重做日志并写入redologbuffer，记录的是数据被修改后的值

第3步:当事务commit时，将redo log buffer中的内容刷新到 redo log file，对 redo log fi1e采用追加写的方式

第4步:定期将内存中修改的数据刷新到磁盘中

1.5、redo log的刷盘策略

InnoDB给出 innodb_flush_log_at_trx_commit 参数，该参数控制 commit提交事务时，如何将 redo log buffer 中的日志刷新到 redo log file 中。它支持三种策略

设置为0:表示每次事务提交时不进行刷盘操作。(系统默认master thread每隔1s进行一次重做日志的同步)

设置为1:表示每次事务提交时都将进行同步，刷盘操作(默认值)

设置为2:表示每次事务提交时都只把redo logbufer 内容写入page cache，不进行同步。由os自己决定什么时候同步到磁盘文件。

2、Undo日志

2.1、如何理解Undo日志

事务需要保证 原子性 ，也就是事务中的操作要么全部完成，要么什么也不做。但有时候事务执行到一半会出现一些情况，比如:

情况一:事务执行过程中可能遇到各种错误，比如服务器本身的错误， 操作系统错误 ，甚至是突然 断电 导致的错误。

情况二:程序员可以在事务执行过程中手动输入ROLLBACK语句结束当前事务的执行。以上情况出现，我们需要把数据改回原先的样子，这个过程称之为 回滚，这样就可以造成一个假象:这个事务看起来什么都没做，所以符合 原子性 要求。

插入一条记录时：记录主键值对应的记录删掉就好了。

删除了一条记录：至少要把这条记录中的内容都记下来

修改了一条记录：至少要把修改这条记录前的旧值都记录下来，这样之后回滚时再把这条记录更新为旧值

此外，undolog会产生redo 10g，也就是undo log的产生会伴随着redolog的产生，这是因为undo log也需要持久性的保护。

2.2、Undo日志作用？

作用1:回滚数据

作用2:MVCC

即在innoDB存储引擎中MVCC的实现是通过undo来完成。当用户读取一行记录时，若该记录已经被其他事务占用，当前事务可以通过undo读取之前的行版本信息，以此实现非锁定读取。

2.3、Undo的存储结构？

1. 回滚段与undo页
   InnoDB对undo log的管理采用段的方式，也就是 回滚段（rollback segment） 。每个回滚段记录了
   1024 个 undo log segment ，而在每个undo log segment段中进行 undo页 的申请。
2. undo页的重用
   undo页就被设计的可以重用了，当事务提交时，并不会立刻删除undo页。因为重用，所以这个undo页可能混杂着其他事务的undo log。undolog在commit后，会被放到一个链表 中，然后判断undo页的使用空间是否 小于3/4，如果小于3/4的话，则表示当前的undo页可以被重用，那么它就不会被回收，其他事务的undolog可以记录在当前undo页的后面。由于undo log是 离散的，所以清理对应的磁盘空间时，效率不高。
3. 回滚段与事务
   ①每个事务只会使用一个回滚段，一个回滚段在同一时刻可能会服务于多个事务。
   ②当一个事务开始的时候，会制定一个回滚段，在事务进行的过程中，当数据被修改时，原始的数据会被复制到回滚段。
   ③在回滚段中，事务会不断填充盘区，直到事务结束或所有的空间被用完。如果当前的盘区不够用，事务会在段中请求扩展下一个盘区，如果所有已分配的盘区都被用完，事务会盖最初的盘区或者在回滚段允许的情况下扩展新的盘区来使用。
   ④回滚段存在于undo表空间中，在数据库中可以存在多个undo表空间，但同一时刻只能使用一个undo表空间。

2.4、回滚段中的数据分类

1、未提交的回滚数据(uncommitted undo information):该数据所关联的事务并未提交，用于实现读一致性，所以该数据不能被其他事务的数据覆盖。

2.已经提交但未过期的回滚数据(committed undo information):该数据关联的事务已经提交，但是仍受到undo retention参数的保持时间的影响。

3.事务已经提交并过期的数据(expired undo information):事务已经提交，而且数据保存时间已经超过undo retention参数指定的时间，属于已经过期的数据。当回滚段满了之后，会优先覆盖"事务已经提交并过期的数据"。

事务提交后并不能马上删除undo log及undo log所在的页。这是因为可能还有其他事务需要通过undolog来得到行记录之前的版本。故事务提交时将undolog放入一个链表中，是否可以最终删除undolog及undo log所在页由purge线程来判断。

2.5、undo log的生命周期

1.简要生成过程

1.start transaction;
2.记录 A=1 到undo log;
3.update A=3:
4.记录 A=3 到redo 1og;
5.记录 B=2 到undo log;
6.update B=4;
7.记录B=4到redo 1og:
8.将redo log刷新到磁盘
9. commit

2.6、小结

undo log是逻辑日志，对事务回滚时，只是将数据库逻辑地恢复到原来的样子。

redo log是物理日志，记录的是数据页的物理变化，undolog不是redo log的逆过程。