MySQL跨行事务模型（图文详解）

MySQL事务模型在网上也有许多的介绍，在写这篇文章此前本人也翻看了许多材料作为参照 ，以期让本人懂得的愈加深入全面。看了大多数介绍文章之后发明部分文章并不完全，比方有的只介绍了几种隔离级别下MySQL的展现，并没有从技术角度停止解读。有的文章说的倒很全面，但缺乏些许层次，读起来并不容易懂得。这也是笔者但愿能够带给大家一点不一样的东西，从技术角度停止解读，并且利于懂得。

MySQL事务原子性包管

事务原子性要求事务中的一系列操纵要末全部完成，要末不做任何操纵，不克不及只做一半。原子性关于原子操纵很容易实现，就像HBase中行级事务的原子性实现就比力简便。但关于多条语句组成的事务来说，假如事务施行历程中发生非常，需要包管原子性就只能回滚，回滚到事务开端前的状态，就像这个事务基本没有发生过一样。怎样实现呢？

MySQL实现回滚操纵完全依靠于undo log，多说一句，undo log在MySQL除了用来实现原子性包管之外，还用来实现MVCC，下文也会触及到。使用undo实现原子性在操纵任何数据此前，第一会将修改前的数据记载到undo log中，再停止实际修改。假如显现非常需要回滚，系统可以利用undo中的备份将数据复原到事务开端此前的状态。下图是MySQL中表示事务的根本数据构造，其中与undo相关的字段为insert_undo和update_undo，离别指向本次事务所发生的undo log。

事务回滚按照update_undo（或者insert_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中行锁机制比力复杂，按照行记载可否是主键索引、独一索引、非独一索引或者无索引等分为多种加锁状况。

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机制实现事务之间的读写并发。只不外两者在实现细节上有一些不同，详细不同接下来再聊。

MVCC in MySQL

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）为trxid，那么：

1. 假如trxid < up_trx_id，说明该行记载所在的事务已经在当前事务创立此前就提交了，所以该行记载对当前事务可见。

2. 假如trxid > low_trx_id，说明该行事务所在的事务是在当前事务创立之后才开启，所以该行记载对当前事务不成见。

3. 假如up_trx_id < trxid < low_trx_id， 那么表白该行记载所在事务在本次新事务创立的时候处于活动状态。从up_trx_id到low_trx_id停止遍历，假如trxid等于他们之中的某个事务id的话，那么不成见，不然可见。

以下面行记载为例，该行记载存在多个版本（trx2、trx5、trx7乃至trx12），其中trx12是最新版本。看看该行记载中哪个版本对当前事务可见。

1. 该行记载的最新版本为trx12，与当前事务read_view停止对照发明，trx12大于当前活泼事务列表中的最大事务trx10，表示trx12是在当前事务创立之后才开启的，因此不成见。

2. 再查看该行记载的第二个最新版本为trx7，与当前事务read_view对照发明，trx7介于当前活泼事务列表最小事务ID和最大事务ID之间，表白该行记载所在事务在当前事务创立的时候处于活动状态，在活泼列表中遍历发明trx7确实存在，说明该事务还没有提交，所以对当前事务不成见。

3. 连续查看该记载的第三个最新版本trx5，也介于当前活泼事务列表最小事务ID和最大事务ID之间，表白该行记载所在事务在当前事务创立的时候处于活动状态，但遍历发明该版本并不在活泼事务列表中，说明trx5对应事务已经提交（注：事务提交时间与事务编号没有任何关联，有大概事务编号大的事务先提交，事务编号小的事务后提交），因此trx5版本行记载对当前事务可见，直接返回。

Read Committed（技术解读：写写并发使用X锁，读写并发使用MVCC幸免脏读）

上文介绍了MySQL中MVCC技术实现机制，但要清楚RC隔离级别下事务可见性，还需要get一个中心点：RC隔离级别下的事务在每次施行select时都会生成一个最新的read_view代替原有的read_view。

如上图所示，左侧为1号事务，在不一样时间点对id=1的记载离别查询了三次。右侧为2号事务，对id=1的记载停止了更新。更新前该记载只要一个版本，更新好变成了两个版本。

1号事务在RC隔离级别下每次施行select恳求都会生成一个最新的read_view，前两次查询生成的全局事务活泼列表中包括trx2，因此按照MVCC规定查到的记载为老版本；最后一次查询的时间点位于2号事务提交之后，因此生成的全局活泼事务列表中不包括trx2，此时在按照MVCC规定查到的记载就是最新版本记载。

Repeatable Read（技术解读：写写并发使用X锁，读写并发使用MVCC幸免不成反复读；当前读使用Gap锁幸免幻读）

和RC模式不一样，RR模式下事务不会再每次施行select的时候生成最新的read_view，而是在事务第一次select时就生成read_view，后续不会再变动，直至当前事务完毕。这样可以有效幸免不成反复读，使得当前事务在整个事务历程中读到的数据都保持一致。示企图如下所示：

这个就很容易懂得，三次查询所使用的全局活泼事务列表都一样，且都是第一次生成的read_view，那之后查到的记载必定和第一次查到的记载一致。

RR隔离级别能够幸免幻读吗？

假如对幻读还不理解的话，可以参照 该系列的第一篇文章。如下图所示，1号事务对针对id>1的过滤前提施行了三次查询，2号事务施行了一次插入，插入的记载恰好相符id>1这个前提。可以看出来，三次查询得到的数据是一致的，这个是由RR隔离级别的MVCC机制包管的。这么看来，是幸免了幻读，但是在最后1号事务在id=2处插入一笔记录，MySQL会返回Duplicate entry的错误，可见幸免了幻读是一种假象。

严厉意义幸免幻读（技术解读：当前读使用Gap锁幸免幻读）

此前提到的所有RR级别的select语句我们称为快照读，快照读能够包管不成反复读，但并不克不及幸免幻读。于是MySQL又提出”当前读”的概念，常见的当前读语句有：

1. select for update

2. select lock in share mode

3. update / delete

并且规定，RR级别下当前读语句会给记载加上一种非凡的锁－Gap锁，Gap锁并不锁定某个详细的记载，而是锁定记载与记载之间的间隔，包管这个间隔中不会插入新的其他记载。下图是一个示企图：

上图中1号事务第一施行了一个当前读的select语句，这个语句会在 id > 0的所有间隔加上Gap锁，接下来2号事务在id = 3处施行插入时系统就会返回Lock wait timeout execcded的非常。当然，其他事务可以在id <= 0的前提下插入成功，这没问题。

Serializable （技术解读：S锁(读)＋X锁(写)）

Serialization隔离级别是最严厉的隔离级别，所有读恳求都会加上读锁，不分快照读和当前读，所有写会加上写锁。当然，这种隔离级别的机能由于锁开销而相对最差。

MySQL事务耐久性包管

MySQL事务耐久化战略和HBase根本雷同，但是触及的组件相对照较多，主要有doublewrite、redo log乃至binlog：

1. MySQL数据耐久化（DoubleWrite）

实际上MySQL的真实数据写入分为两次写入，一次写入到一个称为DoubleWrite的地方，写成功之后再真实写入数据所在磁盘。为什么要写两次？这是由于MySQL数据页大小与磁盘一次原子操纵大小不一致，有大概会显现部分写入的状况，比方默许InnoDB数据页大小为16K，而磁盘一次原子写入大小为512字节（扇区大小），这样一个数据页写入需要屡次IO，这样一旦中心发生非常就会显现数据丧失。别的需要留意的是DoubleWrite机能并不会影响太大，由于写入DoubleWrite是次序写入，对机能影响来说不是很大。

2. redolog耐久化战略（innodb_flush_log_at_trx_commit）

redolog是InnoDB的WAL，数据先写入redolog并落盘，再写入更新到bufferpool。redolog的耐久化战略和HBase中hlog的耐久化战略一致，默许为1，表示每次事务提交之后log就会耐久化到磁盘；该值为0表示每隔1秒钟摆布由异步线程耐久化到磁盘，这种状况下MySQL发生宕机有大概会丧失部分数据。该值为2表示每次事务提交之后log会flush到操纵系统缓冲区，再由操纵系统异步flush到磁盘，这种状况下MySQL发生宕机不会丧失数据，但机器宕机有大概会丧失部分数据。

3. binlog耐久化战略（sync_binlog）

binlog作为Server层的日志系统，主要以events的情势次序纪录了数据库的各种操纵，同时可以纪录每次操纵所花费的时间。在MySQL官方文档上，主要介绍了Binlog的两个最根本中心作用：备份和复制，因此binlog的耐久化会必然程度影响数据备份和复制的完全性。和redo耐久化战略雷同，可取值有0，1，N。默许为0，表示写入操纵系统缓冲区，异步flush到磁盘。该值为1表示同步写入磁盘。为N则表示每写N次操纵系统缓冲就施行一次刷新操纵。

总结一下，本文是数据库事务系列文章的第三篇，中心介绍了MySQL的单机跨行事务模型，其中对隔离性所触及到的锁技术、MVCC机制停止了比力具体的说明。对事务原子性、耐久性等相关特性也停止简便的剖析和说明。接着笔者将会带大家一起聊聊分布式事务模型，看看和单机事务模型到底有何不同。

引荐学习：MySQL教程

以上就是MySQL跨行事务模型（图文详解）的具体内容，更多请关注百分百源码网其它相关文章！