MySQL事务原子性保证

事务原子性要求事务中的一系列操作要么全部完成，要么不做任何操作，不能只做一半。原子性对于原子操作很容易实现，就像HBase中行级事务的原子性实现就比较简单。但对于多条语句组成的事务来说，如果事务执行过程中发生异常，需要保证原子性就只能回滚，回滚到事务开始前的状态，就像这个事务根本没有发生过一样。如何实现呢？

MySQL实现回滚操作完全依赖于undo log，多说一句，undo log在MySQL除了用来实现原子性保证之外，还用来实现MVCC，下文也会涉及到。使用undo实现原子性在操作任何数据之前，首先会将修改前的数据记录到undo log中，再进行实际修改。如果出现异常需要回滚，系统可以利用undo中的备份将数据恢复到事务开始之前的状态。下图是MySQL中表示事务的基本数据结构，其中与undo相关的字段为insert_undo和update_undo，分别指向本次事务中所产生的undo log。

事务回归根据update_undo(或者indert_undo)找到对应的undo log，做逆向操作即可。对于已经标记删除的数据清理删除标记，对于更新数据直接回滚更新；插入操作稍微复杂一些，不仅需要删除数据，还需要删除相关的聚集索引以及更新二级索引记录。

undo log是MySQL内核中非常重要的一块内容，涉及知识比较多而且复杂，比如：
1，undo log必须在修改数据之前持久化，undo log持久化需不需要记录redo以防止宕机异常？如果需要就又涉及宕机恢复。
2，通过undo log如何实现MVCC？
3，那些undo log可以在什么场景下回收清理？如何清理？

MySQL事务一致性保证：强一致性事务保证

MySQL事务隔离级别

Read Uncommitted(RU概述：使用X锁实现写写并发)

Read Uncommitted只实现了写写并发控制，并没有有效的读写并发控制，导致当前事务可能读到其他事务中还未提交的修改数据，这些数据准确性并不靠谱（有可能被回滚），因此在此技术上做出的一切假设就都是不靠谱的。在现实场景中很少有业务会选择该隔离级别。

写写并发实现机制和HBase并无两样，都是使用两阶段锁协议对相应记录加锁实现。不过MySQL中行锁机制比较复杂，根据行记录是否是主键索引、唯一索引、非唯一索引或者无索引等分为多种加锁情况。这里举个简单例子做下说明：update user set userName="libis" where id = 15。

1. 如果id列是主键索引，MySQL只会为聚簇索引记录加锁。
2. 如果id列是唯一二级索引，MySQL会为二级索引叶子节点以及聚簇索引记录加锁。
3. 如果id列是非唯一索引，MySQL会为所有满足条件(id = 15)的二级索引叶子节点以及对应的聚簇索引记录加锁。
4. 如果id列是无索引的，SQL会走聚簇索引全表扫描，并将扫描结果加载到SQL Server层进行过滤，因此InnoDB会为扫描过的所有记录先加上锁，如果SQL Server层过滤不符合条件，InnoDB会释放该锁。因此InnoDB会为扫描到的所有记录都加锁。

接下来无论是RC、RR，亦或是Serialization，写写并发控制都使用上述机制，所以不再赘述。接下来中点分析RC和RR隔离级别中的读写并发控制机制。

在详细介绍RC和RR之前，有必要在此先行介绍MySQL中MVCC机制，因此RC和RR都使用MVCC机制实现事务之间的读写并发。只不过两者在实现细节上有一些区别，具体区别接下来再聊。

MySQL中的MVCC多版本控制机制

MySQL中MVCC机制相比HBase来说要复杂的多，涉及的数据结构页比较复杂。为了解释的比较清晰，以一个例子为模板进行解释。比如当前有一行记录如下图所示：

前面四列是该行记录的实际列值，需要重点关注的是DB_TRX_ID和DB_ROLL_PTR两个隐藏列（对用户不可见）。其中DB_TRX_ID表示修改该行事务的事务ID，而DB_ROLL_PTR表示指向该行回滚段的指针，该行记录上所有版本数据，在undo中都通过链表形式组织，该值实际指向undo中该行的历史记录链表。

现在假设有一个事务trx2修改了该行数据，该行记录就会变为下图形式，DB_TRX_ID为最近修改该行事务的事务ID(trx2)，DB_ROLL_PTR指向undo历史记录链表：

了解了MySQL行记录之后，再来看看事务的基本结构，下图是MySQL的事务数据结构，上文我们提到过。事务在开启之后会创建一个数据结构存储事务相关信息、锁信息、undo log以及非常重要的read_view信息。

read_view保存了当前事务开启时整个MySQL中所有活跃事务列表，如下图所示，在当前事务开启的时候，系统中活跃的事务有trx4、trx6、trx7以及trx10.另外，up_trx_id表示当前事务启动时，当前事务链表中最小的事务ID；low_trx_id表示当前事务启动时，当前事务链表中最大的事务ID。

read_view是实现MVCC的一个关键点，它用来判断记录的哪个版本对当前事务可见。如果当前事务要读取某行记录，该行记录的版本号（事务ID）为trid，那么：

1. 如果trix < up_trx_id，说明改行记录所在的事务已经在当前事务创建之前就提交了，所以该行记录对当前事务可见。
2. 如果trix > low_trx_id，说明该行事务所在的事务是在当前事务创建之后才开启，所以该行记录对当前事务不可见。
3. 如果up_trx_id < trix < low_trx_id，那么表明该行记录所在事务在本次新事务创建的时候处于活动状态。从up_trx_id到low_trx_id进行遍历，如果trxid等于他们之中的某个事务id的话，那么不可见，否则可见。

以下面行记录为例，该行记录存在多个版本(trx2、trx5、trx7以及trx12)，其中trx12是最新版本。看看该行记录中哪个版本对当前事务可见。

1.该行记录的最新版本为trx12，与当前事务read_view进行对比发现，trx12大于当前活跃事务列表中的最大事务trx10，表示trx12是在当前事务创建之后才开启的，因此不可见。

1. 再查看该行记录的第二个最新版本为trx7，与当前事务read_view对比发现，trx7介于当前活跃事务列表最小事务ID和最大事务ID之间，表明该行记录所在事务在当前事务创建的时候处于活动状态，在活跃列表中遍历发现trx7确实存在，说明该事务还没有提交，所以对当前事务不可见。
2. 继续查看该记录的第三个最新版本trx5，也介于当前活跃事务列表最小事务ID和最大事务ID之间，表明改行记录所在事务在当前事务创建的时候处于活动状态，但遍历发现该版本并不在活跃事务列表中，说明trx5对应事务已经提交（注：事务提交时间域事务编号没有任何关联，有可能事务编号大的事务先提交，事务编号小的事务后提交），因此trx5版本行记录对当前事务可见，直接返回。