MySQL undo log专题

基本概念

undo log是一种用于撤销回退的日志。在数据库事务开始之前，MySQL会先记录更新前的数据到undo log日志文件中，当食物回滚时或者数据库崩溃时，可以利用undo log进行回退。
undo log和redo log形式是不一样的。redo log是物理日志，undo log记录的是逻辑日志。

undo log作用

提供回滚操作，实现事务的原子性（事务中的操作要么全部提交要么全部回滚）
比如当delete一条记录时，undo log中就会记录一条对应的insert；执行一个update时则会记录一条相反的update。
提供多版本并发控制（MVCC）
当想要读取某一行被其他事务占锁的数据时，可以从undo log中分析出改行记录以前的版本，从而让用户能够读取当前事务操作之前的数据，这种读也被成为快照读。

undo log存储机制

为了保证事务并发操作时，在写各自的undolog时不产生冲突，innodb采用回滚段的方式来维护undolog的并发写入和持久化。
每个undo表空间中有128个回滚段（rollback segment），每个回滚段中有1024个undo段（Undo Log segment），undo段则记录实际回滚信息，在undo中进行undo页的申请。假设每个事务都要一个undo段，则最多支持128*1024个并发事务的执行。

查看回滚段数量相关参数：

show variables like '%innodb_undo_logs%';

回滚段与事务

1.每个事务只会使用一个回滚段，一个回滚段在同一时刻可能会服务于多个事务。
2.当一个事务开始时，会指定一个回滚段。在数据被修改时，原始的数据会被复制到回滚段中进行记录。
3.在回滚段中，事务会不断填充段区，直到事务结束或空间被用完。如果当前的段区不够用，事务会在段中请求扩展。如果所有的段区都被分配完了，事务会覆盖最初的段区，或者在回滚段允许的情况下，扩展新的段区。
4.回滚段存在于undo表空间中。在数据库中可以有多个undo表空间，5.7版本中undo是在ibdata1系统表空间文件中，8.0以后被移出系统表空间独立出来了，但同一时刻只能使用一个undo表空间。
5.当事务提交时，innodb会做两件事：
1）将undo log放入列表，后台线程会定期进行清洗和清除的操作（因为提交后就不需要回滚了，等待被清洗和清除即可）；
2）判断undolog所在的undo页是否可以重用（低于整个页大小的3/4则可以重用），如果可以则分配给下个事务使用。

回滚段中数据分类

1.未提交的回滚数据：用于实现读的一致性。事务关联的数据还没提交，该数据是不能被其他事务的数据覆盖的。
2.已提交但是未过期的回滚数据：该数据相关的事务已经提交，但是未过期。（过期由相关参数进行配置）
3.事务已提交且过期的回滚数据：已提交且过期的数据，在回滚段满了之后会被优先覆盖。

undo页的重用

假设TPS=1000，一个事务用一个页，就需要1000个页，太浪费了。
因此undo页被设计为可重用的。
但注意事务提交时不会立刻删除undo页，因为重用的原因，当前undo页可能有其他事务的记录。
Undo Log在commit后，会被放到一个链表中，然后判断Undo页的使用空间是否小于3/4，如果小于3/4的话，则表示当前的Undo页可以被重用，那么它就不会被回收，其他事务的Undo Log可以记录在当前Undo页的后面。由于Undo Log是离散的，所以清理对应的磁盘空间时，效率不高。

undo log存储的信息

undolog不单存储了数据更新前的记录，还包括了rowid、事务id、回滚指针。

Rowid：如果一张表没有显示定义主键，也没定义唯一索引，则innodb会自动添加Rowod隐藏列作为主键，是不可见的。
TX_id：事务对某条记录进行DML操作时，就会将这个事务的事务id写到trx_id字段中，可通过information_schema.INNODB_TRX系统视图查询。
ROL_PT：回滚指针，指向历史版本的undolog的指针，也是不可见的。

在undo日志中事务id每次递增，回滚指针第一次如果是insert语句，回滚指针就是null，第二次update之后undo日志的回滚指针就会指向上一版本的日志记录，依次类推就会形成一个undo log回滚链，方便找到该条记录的某个历史版本。

参考下图：

undo log工作原理