mysql面试关键知识点：undo log

案例1：数据库不可重复读问题

大家都知道，数据库的四个隔离级别。有一个情况大家也熟悉：即RC和RR两种隔离级别下的不同可见性，即不可重复读问题。

不可重复读的含义是事务A多次读取同一数据，事务B在事务A多次读取的过程中，对数据做了更新并提交，导致事务A多次读取时数据不一致

在RC隔离级别下，伪代码

session1
start transaction;

session2
start transaction;

session1先读取一次，是1200
session2加了300，之后commit
session1再读取一次，是1500

如果session1基于1200进行了操作，就可能造成数据紊乱的结果

而在RR隔离级别下，结果

会发现session1读取的结果一致都是第一次start transaction之前数据的值，在整个session过程中不变，比如说都是1200

而在RR隔离级别下，如果我就在这个基础上做修改，会存在问题吗？

session2 1500
session1 read 仍是1200，但其执行
UPDATE account_innodb SET balance = balance - 100 WHERE id = 1;
commit;
再查询，结果是1400，是正确的，而不是我们之前预想的1100	

案例2：innodb快照读

比如说在session1中对id=3的数据加共享读锁，

SELECT * FROM person_info_large WHERE id = 3;

在session2中对id=3的数据添加排他锁（更新操作），原则上更新操作是会被hang住的

UPDATE person_info_large SET title = "test333" WHERE id = 3;

但结果居然成功了

因为在session1中我们并没有commit，只有commit了才会释放共享读锁的

这完全颠覆了我们之前认识的：在共享读锁加锁的情况下，无法再添加排他写锁的认知

其实呢，是innodb对select进行了改进，session1中的select并未对该行上锁，所以才导致更新是成功的，这就是非阻塞select（快照读）

以上两个问题的解决就是由undo log来提供支持的。

undo log功能

undo log用来实现事务的一致性，即事务ACID中的C–consistence，支持回滚和MVCC多版本控制。本质上是一种恢复操作，其恢复操作是回滚行记录到某个特定版本。

当我们在事务中对记录做了变更操作时，就会产生undo日志。undo日志中存储的是老版数据，当一个旧的事务要去读取数据时，为了能够读取到老版本的数据，需要顺着undo列找到满足其可见性的记录。

undo log组成

物理层面上：

undo log是记录到undo page中的

在mysql 5.5中，默认存放在 ibdata1中，即系统表空间中。

在mysql5.6中，提供了undo表空间。

undo log的记录结构

undo log 是逻辑记录，记录了每一行修改的值（前后项）。

undo log主要分为两种：insert undo log和update undo log。

• insert undo log表示的是事务对insert新纪录产生的undo log，只在事务回滚时需要，并且可以在事务提交时就可以丢弃。
• 重点是update undo log，事务对记录进行update或者delete操作时会产生update undo log，不仅在事务回滚时需要，快照读也需要，所以不能随便删除，只有当数据库所使用的快照中不涉及该日志记录，对应的回滚日志才会被purge线程删除。

undo log工作过程

在innodb每行记录中，有两个列是隐藏的，一个是事务的id列 trx id，另一个是回滚指针列 roll pointer

• DB_TRX_ID字段标识最近一次对本行记录做修改，insert或update的事务id，至于说delete操作，在innodb看来，也不过是一次update操作，有一个deleted的隐藏列
• DB_ROLL_PTR (rollback pointer)，即回滚指针，指写入回滚段rollback segment的undo日志记录，如果一行记录被更新，则undo log record包含重建该行记录被更新之前内容所必须的信息

undo log日志的工作方式简化的演示，这里只是显示了事务对行记录的更新过程（innodb在内部做了非常多的工作）

上图表示我们对DB_ROW_ID=1的行做了update，这一行被事务A（事务id：1）做了修改，将原来field2里面的值由12更新为了32。

其修改的过程是这样的：

1. 首先用排他锁锁定该行

2. 然后把该行修改前的值copy一份到undo log里面

3. 之后修改当前行的值，填写事务id到DB_TRX_ID，使用DB_ROLL_PTR回滚指针指向undo log中修改前的行

在这之后，如果数据库中还有别的事务再用快照读来读取该日志记录，那么对应的undo log还没有被清除。

此时某个事务又对同一行记录做了修改，将其fields3的值由13修改为了45

这样又会多了一条undo log记录，数据的多个版本就是这样实现的

其实现了伪MVCC，为什么这里只实现了伪MVCC功能呢？因为其并没有实现核心的多版本共存，undo log中的内容只是串行化的结果，记录了多个事务的过程，不属于多版本共存。

对事务回滚的支持

以上就是undo log的大概样子，它按照修改的时间顺序从今到远，通过DB_ROLL_PTR给连接起来了，这样的方式就支持了事务回滚。

对快照读的支持

read view

主要是用来做可见性判断的，即当我们去执行快照读select的时候，会针对我们查询的数据创建出一个read view，来决定当前事务能看到的是哪个版本的数据。有可能是当前最新版本的数据，也有可能是undo log中某个版本的数据。

read view遵循一个可见性算法，当select的时候，主要是将要修改数据的DB_TRX_ID取出来，与系统其它活跃事务ID做对比，如果大于或者等于这些ID的话，就通过DB_ROLL_PTR指针去取出undo log上一层的DB_TRX_ID，直到小于这些活跃事务ID为止，这样就保证了我们当前取到的数据版本是当前可见的最稳定的版本。

可以看mysql的源码

可以看到其有m_low_limit_id和m_up_limit_id

每当我们start transaction的时候，事务id都会递增，也就是说越新开启的事务，其id就越大。

我们主要就是通过这两个值，去和我们的DB_TRX_ID做对比，进而决定是不是去回溯到的undo log，去取出适应该版本的一个数据的版本来。

总结：正是因为生成时机的不同，造成了RC、RR两种隔离级别下的不同可见性。

不可重复读

在repeatable read级别下，session在start transaction后的第一条快照读，会创建一个快照，即read view，将当前系统中活跃的其他事务记录起来，此后再调用快照读的时候，还是使用的同一个read view。

而在read committed级别下，事务中每条select语句，每次调用快照读的时候，都会创建一个新的快照，这就是为什么之前，我们在RC级别下，能用快照读看到别的事务已经提交到的对表记录的增删改。而在RR级别下，如果首次使用快照读，是在别的事务对数据库记录进行增删改并提交之前的，此后即便别的事务对记录进行了增删改并提交，还是读不到数据的变动的原因。

对RR来说，首次事务select的时机是相当重要的。

所以，在RC下可以看到两次select的结果不同，而在RR下，都是读取同一个快照，所以每次select的结果相同

非阻塞读就是读不加锁，读写不冲突，在读多写少的OLTP中，极大增加了系统的并发功能。

undo log清理–purge线程

删除undo log，执行真正的删除记录

举例：表tb1 中有记录pk=1，2，3；此时delete from tb1 where pk=1;

1. 将pk=1的记录标记为删除（delete-mark，info bits），数据库中pk=1的记录此时还是存在的，空间并没有被释放，该操作为同步操作（SQL执行完，也就标记完成了）。

2. purge，该部分为后台线程（purge线程）异步操作，会真正的删除该记录，且空间被释放。purge线程是系统自动的，无法人工控制。

标记为已删除的原因：

1. 该事务可能需要回滚，先作保留。
2. 当事务1 去删除pk=1且没有提交时， 事务2 应该要能看到pk=1的记录（事务的隔离性）。

purge线程不处理insert

1. insert操作是不需要异步去purge，因为insert的记录之前是不存在的
2. 不存在记录（未提交）是没有别的事务能引用到的，所以insert事务执行完成之后，对应的undo可以直接删除，而不需要等待异步purge

redo log与undo log对比

1. redo log用来保证事务的原子性和持久性，undo log用来保证事务的一致性，用来实现事务回滚及MVCC的功能。
2. redo log和undo log都可以看做是一种恢复操作，redo log恢复提交事务修改的页操作，而undo回滚行记录到某个特定版本，因此两者记录的内容不同。而且redo是物理逻辑日志，根据页进行记录（物理），记录的是页的变化（逻辑），而undo log是逻辑日志，根据每行记录进行记录。
3. redo log基本上都是顺序写的（其写checkout LSN是随机写的），在数据库运行时不需要对redo log的文件进行读取操作。而undo log是需要进行随机读写的。