MySQL 事务的实现原理之 Undo Log 的分析

Undo Log 日志是何许人也

MySQL 事务中，主要的功能特性，依赖于 Undo log ,因为四个特性

• 原子性， 持久性----> Redo log

• 隔离性 ----->MVCC 机制和锁

• 一致性 ----->Undo log

因为 Undo log 在 Mysql 事务实现中，主要有两方面，

• 多版本的并发事务控制-MVCC 版本

• 回滚事务

undo Log 的产生过程

在 MySQL 事务开始之前，比如我有一个查询的数据的功能， 在识别到当前可能会查询到这个表的数据后， 然后快照其中的数据， 如果 数据库的事务 发生回滚操作， 或者是数据库发生异常导致宕机或者是故障，这时候 Undo log,对数据库中未提交的事务进行回滚操作， 从而保证数据库中， 数据查询到的数据的一致性。

本质： undo log 是 为了回滚事务存在。

Undo log 日志属于逻辑日志，相比于 Redo log 的物理日志，（操作性的），这个日志记录的是数据快照和当前数据 反向事务， 举个例子，

如果我先需要 insert 一条数据 ，到用户表中，场景是我注册了一个新的用户，但是在这个事务，也就是说 Mysql 接到这个添加的事务请求开始时候，先进行数据快照，然后在运行的过程中，会添加一个 undo log 日志是删除这条产生的数据 delete 语句， 也即是说会回滚 事务--。

同理可得， 如果说是 delete 事务， undo log 就会产生 一条 insert 的数据， 因为这个日志就是为了回滚日志产生的。

undo log 的 MVCC 的版本控制

mvcc 多路并发的版本控制， 简单理解就是，为了标记数据的更新的版本，创建了两个隐藏列--->

• 保存行的创建版本

• 保存行的 删除版本（更新，删除都可以）

其中对于，自己 InnoDb 引擎，产生 Undo log 也需要进行持久化的操作， 所以 Undo lgo 也会产生 Redo log ,由于 Undo log 的完整性和可靠性需要 Redo log 来保证，因此数据库奔溃的时候，

需要先做物理的 Redo log 数据恢复，然后做 Undo log 回滚。