7 mysql事务（包括redo log，undo log，MVCC）及事务实现原理

之前写了几篇mysql存储原理的文章。

6 Innodb_buffer_pool

5 b+ tree和每个page存储结构

4 innodb文件系统基本结构（段、簇、页面）

3 innodb文件系统初步入门

2 表对象缓存

1 连接层

这一篇终于到事务了，事务大家都知道ACID概念，那么mysql是如何完成事务的呢？

先来看结论——

原子性：

一次事务中的所有操作，要么全部完成要么全部不执行。这里是通过undo log来实现的。

undo log又是什么呢，可以理解为要执行的sql的反向sql，也就是回滚sql。譬如你insert了一条，undo log里就会保存一个delete xxx id = xxx。

持久性：

一旦一个事务被提交，就算服务器崩溃，仍然不能丢数据，在下次启动时需要能自动恢复。这里是通过redo log实现的。

那么如何才能持久呢，很简单，写入硬盘就行了。通过前面几篇的学习，我们知道mysql大部分时间是在Innodb_buffer_pool里做内存读写的，特定情况下才会落盘。这样如果突然服务器崩溃，没来得及落盘的数据就会丢失。所以有了redo log顺序写磁盘（顺序写速度极快，后续的落盘是随机写，速度慢），在事务提交后，事务日志会顺序写入磁盘，然后写入pool内存里。然后才是后续的那些按规则将索引数据落盘。

隔离性：

事务的隔离性是通过读写锁+MVCC来实现的。mysql在为了并发量和数据隔离方面做了很多的尝试，其中MVCC就是比较好的解决方案。

也就是面试最常见的4大隔离级别。

       1.读未提交          其它事务未提交就可以读
       2.读已提交          其它事务只有提交了才能读
       3.可重复读          只管自己启动事务时候的状态,不受其它事务的影响(mysql默认)
       4.事务串行          按照顺序提交事务保证了数据的安全性,但无法实现并发

一致性：

即数据一致性，是通过上面的三种加起来联合实现的。

ACID只是个概念，最终目的就是保证数据的一致性和可靠不丢。

 

Undo Log

所谓的undo log就是回滚日志，当进行插入、删除、修改操作时，一定会生成undo log，并且一定优先于修改后的数据落盘。

我直接借用别人的图了，zhangsan的银行账户有1000元，他要转400元到理财账户。

可以看到，每一条变更数据的操作，都伴随一条undo log的生成。undo log就是记录数据的原始状态。这一点在一些其他的分布式事务的框架里也有所使用，譬如seata就是采用自己解析sql并生成反向sql存储下来，将来抛异常时就执行回滚语句的方式来做的分布式事务，而不借助于mysql自身的undo log机制。

有了undo log，如果事务执行失败要回滚，那很简单，直接将undo log里的回滚语句执行一遍就好了。mysql就是通过这种方式完成的原子性。

Redo Log

redo log是完成数据持久性的，事务一旦提交，其所做的修改就会永久保存到数据库中，而不能丢失，即便是mysql服务器挂掉了也不能丢。

mysql数据是存储到磁盘的，但读写其实都是操作的buffer pool缓存（前面几篇讲过insert buffer）。这样就会造成写入时，如果仅仅写入到buffer pool了，还没来得及刷入数据页，那么mysql突然宕机，就会丢失数据。

此时redo log的作用就出来了，在写入buffer pool后会同时写入到redo log（顺序写磁盘）一份，redo log有固定的大小，会被重复使用。

MVCC及隔离级别

mvcc是什么

MVCC (MultiVersion Concurrency Control) 叫做多版本并发控制。理解为：事务对数据库的任何修改的提交都不会直接覆盖之前的数据，而是产生一个新的版本与老版本共存，使得读取时可以完全不加锁。

有点抽象是吗，再来详细解释一下。同一行数据会有多个版本，某事务对该数据的修改并不会直接覆盖老版本，而是产生一个新版本和老版共存。然后在该行追加两个虚拟的列，列就是进行数据操作的事务的ID（created_by_txn_id），是一个单调递增的ID；还有一个deleted_by_txn_id，将来用来做删除的。

那么在另一个事务在读取该行数据时，由具体的隔离级别来控制到底读取该行的哪个版本。同时，在读取过程中完全不加锁，除非用select * xxx for update强行加锁。

譬如read committed级别，每次读取，总是取事务ID最大的那个就好了。

对于Repeatable read，每次读取时，总是取事务ID小于等于当前事务的ID的那些数据记录。在这个范围内，如果某一数据有多个版本，则取最新的。

MVCC在mysql中的实现依赖的是undo log与read view

undo log记录某行数据的多个版本的数据；read view用来判断当前版本数据的可见性。

mysql就是用MVCC来实现读写分离不加锁的。

那么MVCC里多出来的那些版本的数据最终是要删除的，支持MVCC的数据库套路一般差不多，都会有一个后台线程来定时清理那些肯定没用的数据。只要一个数据的deleted_by_txn_id不为空，并且比当前还没结束的事务ID最小的一个还小，该数据就可以被清理掉了。在PostgreSQL中，该清理任务叫“vacuum”，在Innodb中，叫做“purge”。

 

隔离级别

隔离级别目的很明确，管理多个并发读写请求的访问顺序，包括串行和并行，要在并发性能和读取数据的正确性上做个权衡。

其中的两个隔离级别Serializable和 Read Uncommited几乎用不上，这里不谈。

Read Committed

能读到其他事务已提交的内容，这是Springboot默认的隔离级别。一个事务在他提交之前的所有修改，对其他事务不可见。提交后，其他事务就能读到了。在很多场景下这种逻辑是可以接受的。

在这个隔离级别下，读取数据不加锁而是使用MVCC机制，写入数据就是排他锁。该级别会产生不可重复读和幻读问题。

不可重复读就是在一个事务内多次读取的结果不一样，这个很容易理解，上面讲MVCC时也说了，该级别每次select时都会去读取最新的版本，所以同一个事务内，也就是代码前面一行select了，后面又select了，可能会select到不同的值。因为这两次select过程中，有其他事务对select的行进行了事务提交，就会被select出来最新的。

幻读，即一个事务能够读取到插入的新数据。会出现幻读也是一样的道理，第一次select时还没值，再次select时又有值了。

Repeatable Read

这个级别名字就是可重复读，这是mysql默认的隔离级别。

为什么能重复读，前面讲MVCC时也说了，这个级别下，一旦读到某个版本，后续都是这个版本了，好比是一次快照，就不关心其他事务对该行数据的提交了，它只认第一次读取时的版本号。

这个级别在一些场景下很重要，如

     数据备份：
             例如数据库S从数据库M中复制数据，但是M又不停的在修改数据。S需要拿到M的一个数据快照，但又不能停M。
     数据合法性校验：
             例如有两张表，一张记录了当时的交易总额，另一张记录了每个交易的金额。那么在读取数据时，如果没有快照的存在，交易总额就可能和当时的交易总额对不上。

该级别依然会出现幻读的问题，repeatable是可以出现幻读的，一个事务虽然不能读取其他事务对现有数据的修改，但是能够读取到插入的新数据。

即便是MVCC也解决不了幻读的问题，这里有一篇讲的原因。

写前提困境

尽管在MVCC的加持下Read Committed和Repeatable Read都可以得到很好的实现。但是对于某些业务代码来讲，在当前事务中看到/看不到其他的事务已经提交的修改的意义不是很大。这种业务代码一般是这样的：

    先读取一段现有的数据

    在这个数据的基础上做逻辑判断或者计算；

    将计算的结果写回数据库。

这样第三步的写入就会依赖第一步的读取。但是在1和3之间，不管业务代码离得有多近，都无法避免其他事务的并发修改。换句话说，步骤1的数据正确是步骤3能够在业务上正确的前提，这样其实与MVCC都没什么关系了，因为我们想象中的要操作的数据和实际值并不一样，无论怎么步骤3的结果其实都不对了。

无论你用哪种隔离，你都无法解决第一步读取的数据和第三步操作之间，别的事务对它的修改。

解决方法：

结论

虽然上面写了很多，也很复杂，貌似不上锁怎么都难以解决写前提困境。而事实上，我们几乎不用考虑这样的场景，极少有可能说多个客户端同时操作同一条数据，又刚好碰上需要抉择read committed还是Repeatable read的困境。

结论很简单，不管他就好，你几乎没机会碰到这样的选择困境。