MySQL之undo日志_代码007(未授权)

undo log（回滚事务），在事务没有提交前，MySQL将记录更新操作的反向操作到undo log 日志中，以便进行回退保证事务的原子性

1.提供回滚操作

我们在进行数据更新操作的时候，不仅会记录 redo lo g，还会记录undo log，如果因为某些原因导致事务回滚，那么这个时候MySQL就要执行回滚（roll b ack）操作，利用undo log将数据恢复到事务开始之前的状态。

2、提供多版本控制(MVCC)

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

1.回滚段和undo页

1、未提交的回滚数据：该回滚数据关联的事务尚未提交，要用于实现MVCC，所以不能被删除和覆盖；

2、已提交但未过期的回滚数据：该回滚数据关联的事务已提交，但仍然受到undo retention参数的影响继续保留；

在InnoDB中，undo log分为两种：

对于InnoDB来说，每条记录不仅包括了自身的数据，还包含了几个隐藏列：

start transaction;
insert into user(name) values('Tom');
commit;

此时行记录deletemark标记为0，表示该记录并未删除，回滚指针指向了回滚编号为0的回滚日志，回滚日志记录了主键信息，说明若要回滚操作可以通过执行delete这个主键实现。

start transaction;
update user set name = 'Sun' where id = 1;
commit;

此时执行了更新操作，并且更新的字段不是主键。此时记录的回滚指针指向了新生成的回滚编号为1的undo log，编号为0的undo log连接在编号为1的后面，当年记录回滚时也是先通过编号1的undo log恢复到name为'Tom'，再通过编号0的undo log删除记录。

start transaction;
update user set id = 2 where id = 1;
commit;

对于更新主键的操作，会先把原来的数据deletemark标识标记为1，这时并没有真正的删除数据，真正的删除会交给purge清理线程去判断，然后在后面插入一条新的记录，新的记录也会产生undo log，并且undo log的序号会递增。

删除操的undo log只需要考虑对删除操作在阶段1所做的影响进行回滚，需要把该记录的trx_id和roll_pointer的隐藏列旧值都记到对应的undo log中的trx_id和roll_pointer属性中。可以通过删除操作的undo log的roll_pointer的属性找到上一次对该记录改动产生的undo log，以此来实现回滚。