1. 事务的执行流程

事务执行流程.png

当我们对数据库执行增删改操作时，不可能直接更新磁盘上的数据，如果实际上针对的是内存里面的Buffer Pool中的数据进行的。Buffer Pool中数据会异步的刷新到磁盘上（刷脏）。

如上图所示，事务执行流程步骤（更新操作）：

1. 查询数据若Buffer Pool存在，则输出，不存在则读取磁盘中的数据并放入Buffer Pool；
2. 更新操作，会先将数据的旧值写入undo log，以便回滚。（保证原子性）；
3. 更新Buffer Pool（内存）数据；
4. 将更新数据写入到Redo Log Buffer（内存中）；
5. 准备提交事务，会调用fsync将Redo Log Buffer的值刷入到redo log日志文件中，状态为prepare；
6. 准备提交事务，binlog 日志写入磁盘；
7. binlog写入成功后，将redo log的状态变更为commit；

2. 事务实现的原理

事务实现的原理，我认为便是事务如何保证ACID，即原子性，一致性，隔离性，持久性。

2.1 原子性

InnoDB依赖undo log实现原子性。当事务对数据库进行修改时，InnoDB会生成对应的undo log日志。如果事务执行失败或者调用rollback，导致事务回滚，便可以利用undo log中的信息将数据回滚到修改之前的样子；

undo log是逻辑日志，记录的是sql执行相关的信息，当发生回滚时，InnoDB会根据undo log的内容做与之前相反的工作：

1. 对于insert，回滚时会执行delete；
2. 对于delete，回滚时会执行insert；
3. 对于update，回滚时会执行一个相反的update；

2.2 隔离性

mysql的隔离性依赖的是MVCC或者锁来实现的，mvcc本质依旧是依赖undo log生成版本快照。

MVCC我知道，但是为什么要设计间隙锁？

2.3 持久性

持久性依赖的是redo log来保证。这里简述下：为了减少与磁盘的交互次数，mysql的更新操作只会更新Buffer Pool（内存）级别。Buffer Pool中的数据会定时的写入到磁盘中，但是引入了一个新问题？当mysql宕机时，如何保证数据不丢失？

依赖的就是redo log来实现，具体是通过WAL（Write-ahead Logging 预写式日志）来实现，即先写入日志，在更新到Buffer Pool，以保证系统宕机后可以安全恢复。

mysql的一个update需要经历什么最终持久化到磁盘？

2.4 一致性

一致性是事务追求的最终目标，上面说到的原子性、隔离性、持久性都是为了保证数据库状态的一致性。当然除了数据库层面的保障，一致性的实现也需要应用层面的保障。

3. 概念-redo log和undo log

浅析MySQL事务中的redo与undo

3.1 redo log

在InnoDB存储引擎中，大部分Redo log记录的是物理日志，即数据页的物理变化。主要用于解决数据库崩溃后安全恢复。

一般由两个部分组成：

1. 内存中重做日志缓冲（redo log Buffer）易丢失，在内存中；
2. 重做日志文件（redo log file），保存在磁盘中。

redo log写入时机：

数据页修改完成后，在脏页刷出磁盘之前，写入redo log日志。注意是先修改数据，在写入日志。

mysql的一个update需要经历什么最终持久化到磁盘？

3.2 undo log

undo log的定义

undo log主要记录的是数据的逻辑变化，为了在发生错误时回滚之前的操作，需要将之前的操作都记录下来，然后在发生错误时才可以回滚。

undo log的作用

1. 用于事务的回滚（保证原子性）；
2. 用于MVCC（保证一致性）；

undo log的写入时机

• DML操作修改聚簇索引前，记录undo日志
• 二级索引记录的修改，不记录undo日志

需要注意的是，undo页面的修改，同样需要记录redo日志。

undo的类型

在InnoDB存储引擎中，undo log分为：

1. insert undo log：指在insert 操作中产生的undo log，因为insert操作的记录，只对事务本身可见，对其他事务不可见。故该undo log可以在事务提交后直接删除，不需要进行purge操作。
2. update undo log：记录的是对delete 和update操作产生的undo log，该undo log可能需要提供MVCC机制，因此不能再事务提交时就进行删除。提交时放入undo log链表，等待purge线程进行最后的删除。

purge线程两个主要作用是：清理undo页和清除page里面带有Delete_Bit标识的数据行。在InnoDB中，事务中的Delete操作实际上并不是真正的删除掉数据行，而是一种Delete Mark操作，在记录上标识Delete_Bit，而不删除记录。是一种"假删除",只是做了个标记，真正的删除工作需要后台purge线程去完成。

3.3 总结

redo log + undo log的简化过程

假设有A、B两个数据，值分别为1,2.
1. 事务开始
2. 记录A=1到undo log
3. 修改A=3
4. 记录A=3到 redo log
5. 记录B=2到 undo log
6. 修改B=4
7. 记录B=4到redo log
8. 将redo log写入磁盘
9. 事务提交

undo log 是否是redo log的逆过程？

不是，undo log是逻辑日志，对事务回滚时，只是将数据库逻辑恢复成原来的样子，而redo log是物理日志，记录的是数据页的物理变化。

推荐阅读

理解Mysql中的Buffer pool
最详细的MySQL事务特性及原理讲解！（一）
浅析MySQL事务中的redo与undo