MYSQL的事务隔离级别，MVCC，readView和版本链小结

MVCC(Mutil-Version Concurrency Control)，就是多版本并发控制。这种并发控制的方法，主要应用在RC和RR隔离级别的事务当中，利用执行select *** 作时，访问记录版本链，使得不同事物的读写，写读可以并发执行，提高系统性能。

Innodb 有两个隐藏字段 trx_id(事务id)和roll_pointer(回滚指针)。

transaction id ：

innoDB里面每个事务有一个唯一的事务ID，叫作transaction id，它是在事务开始的时候向InnoDB的事务系统申请的，是按申请顺序严格递增的。

roll_pointer ：

指向上一事务版本的指针。

版本链 ：

是一个单链表结构，对于同一行数据，每一个事务对其进行更新的时候都会产生一个新的版本，就会存储在这个链表当中。

一个存储事务id的列表。

readview的几个参数：

m_ids:表示活跃事务id列表

min_trx_id:活跃事务中的最小事务id

max_trx_id:已创建的最大事务id

creator_trx_id:当前的事务id。

readview的生成时机：

RC隔离级别：每次读取数据前，都生成一个readview；

RR隔离级别：在第一次读取数据前，生成一个readview；

使用场景：

[ 创建事务节点 ] 当我创建一个新的事务需要读取一行数据, 我会查询活跃的事务列表; 假设我当前的事务id是200, 当前活跃的事务id没有我的200, 因此需要去拷贝一个最新的不活跃事务并在版本链最后插入一个新节点200; mysql会去对比版本链和readView, 假设版本链数据为[1,50,100,150], 活跃列表为[100,150], 说明100和150都是未提交的活跃事务, 再向前一个节点50不在活跃事务列表说明事务50已经提交, 所以事务200拷贝事务50并插入版本链最后, 且将200追加到readView活跃列表的最后一个元素

[ 使用事务节点 ] 当我再次进行200号事务的查询或修改, 我需要读版本链的数据, 因为上一次 *** 作已经在版本链做了200号节点, 因此我读的数据都是200号节点的数据, 这样就隔离了其他未提交的事务; 我的全部增删查改都在200号版本链上进行

[ readView实现事务隔离级别 ]以上两点都是基于隔离级别"读已提交"来进行说明的; 当mysql设置为"可重复读"时, 不同事务仍然是保存在版本链的不同节点上, 只不过新的事务创建的时候拷贝了当下的readView列表, 只要新事物不提交就一直使用这个拷贝的活跃列表; 假设此时100号数据提交了, 我在新事务执行了select 会去查活跃列表发现100号事务还是未提交状态, 因此读取到的还是50号事务提交的记录。

原子性，一致性，隔离性，持久性。

未提交读（read uncommitted）、提交读（read committed）、可重复读（repeatable read）、序列化读（serializable）

分别是原子性、一致性、隔离性、持久性。

原子性是指事务包含的所有 *** 作要么全部成功，要么全部失败回滚，因此事务的 *** 作如果成功就必须要完全应用到数据库，如果 *** 作失败则不能对数据库有任何影响。

一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。举例来说，假设用户A和用户B两者的钱加起来一共是1000，那么不管A和B之间如何转账、转几次账，事务结束后两个用户的钱相加起来应该还得是1000，这就是事务的一致性。

隔离性是当多个用户并发访问数据库时，比如同时 *** 作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的 *** 作所干扰，多个并发事务之间要相互隔离。关于事务的隔离性数据库提供了多种隔离级别，稍后会介绍到。

持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的 *** 作。例如我们在使用JDBC *** 作数据库时，在提交事务方法后，提示用户事务 *** 作完成，当我们程序执行完成直到看到提示后，就可以认定事务已经正确提交，即使这时候数据库出现了问题，也必须要将我们的事务完全执行完成。否则的话就会造成我们虽然看到提示事务处理完毕，但是数据库因为故障而没有执行事务的重大错误。这是不允许的。

在数据库 *** 作中，在并发的情况下可能出现如下问题：

正是为了解决以上情况，数据库提供了几种隔离级别。

数据库事务的隔离级别有4个，由低到高依次为Read uncommitted(未授权读取、读未提交)、Read committed（授权读取、读提交）、Repeatable read（可重复读取）、Serializable（序列化），这四个级别可以逐个解决脏读、不可重复读、幻象读这几类问题。

虽然数据库的隔离级别可以解决大多数问题，但是灵活度较差，为此又提出了悲观锁和乐观锁的概念。

悲观锁，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度。因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制。也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统的数据访问层中实现了加锁机制，也无法保证外部系统不会修改数据。

商品t_items表中有一个字段status，status为1代表商品未被下单，status为2代表商品已经被下单（此时该商品无法再次下单），那么我们对某个商品下单时必须确保该商品status为1。假设商品的id为1。

如果不采用锁，那么 *** 作方法如下：

但是上面这种场景在高并发访问的情况下很可能会出现问题。例如当第一步 *** 作中，查询出来的商品status为1。但是当我们执行第三步Update *** 作的时候，有可能出现其他人先一步对商品下单把t_items中的status修改为2了，但是我们并不知道数据已经被修改了，这样就可能造成同一个商品被下单2次，使得数据不一致。所以说这种方式是不安全的。

在上面的场景中，商品信息从查询出来到修改，中间有一个处理订单的过程，使用悲观锁的原理就是，当我们在查询出t_items信息后就把当前的数据锁定，直到我们修改完毕后再解锁。那么在这个过程中，因为t_items被锁定了，就不会出现有第三者来对其进行修改了。需要注意的是，要使用悲观锁，我们必须关闭mysql数据库的自动提交属性，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新 *** 作后，MySQL会立刻将结果进行提交。我们可以使用命令设置MySQL为非autocommit模式： set autocommit=0;

设置完autocommit后，我们就可以执行我们的正常业务了。具体如下：

上面的begin/commit为事务的开始和结束，因为在前一步我们关闭了mysql的autocommit，所以需要手动控制事务的提交。

上面的第一步我们执行了一次查询 *** 作： select status from t_items where id=1 for update; 与普通查询不一样的是，我们使用了 select…for update 的方式，这样就通过数据库实现了悲观锁。此时在t_items表中，id为1的那条数据就被我们锁定了，其它的事务必须等本次事务提交之后才能执行。这样我们可以保证当前的数据不会被其它事务修改。需要注意的是，在事务中，只有 SELECT FOR UPDATE 或 LOCK IN SHARE MODE *** 作同一个数据时才会等待其它事务结束后才执行，一般 SELECT 则不受此影响。拿上面的实例来说，当我执行 select status from t_items where id=1 for update; 后。我在另外的事务中如果再次执行 select status from t_items where id=1 for update; 则第二个事务会一直等待第一个事务的提交，此时第二个查询处于阻塞的状态，但是如果我是在第二个事务中执行 select status from t_items where id=1; 则能正常查询出数据，不会受第一个事务的影响。

使用 select…for update 会把数据给锁住，不过我们需要注意一些锁的级别，MySQL InnoDB默认Row-Level Lock，所以只有「明确」地指定主键或者索引，MySQL 才会执行Row lock (只锁住被选取的数据) ，否则MySQL 将会执行Table Lock (将整个数据表单给锁住)。举例如下：

1、 select from t_items where id=1 for update;

这条语句明确指定主键（id=1），并且有此数据（id=1的数据存在），则采用row lock。只锁定当前这条数据。

2、 select from t_items where id=3 for update;

这条语句明确指定主键，但是却查无此数据，此时不会产生lock（没有元数据，又去lock谁呢？）。

3、 select from t_items where name='手机' for update;

这条语句没有指定数据的主键，那么此时产生table lock，即在当前事务提交前整张数据表的所有字段将无法被查询。

4、 select from t_items where id>0 for update; 或者 select from t_items where id>1 for update; （注：>在SQL中表示不等于）

上述两条语句的主键都不明确，也会产生table lock。

5、 select from t_items where status=1 for update; （假设为status字段添加了索引）

这条语句明确指定了索引，并且有此数据，则产生row lock。

6、 select from t_items where status=3 for update; （假设为status字段添加了索引）

这条语句明确指定索引，但是根据索引查无此数据，也就不会产生lock。

乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以只会在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则返回用户错误的信息，让用户决定如何去做。实现乐观锁一般来说有以下2种方式：

当我们使用 MySQL 进行数据存储时，一般会为一张表设置一个自增主键，当有数据行插入时，该主键字段则会根据步长与偏移量增长（默认每次+1）。

下文以 Innodb 引擎为主进行介绍，使用自增主键的好处有很多，如：索引空间占比小、范围查询与排序都友好、避免像 UUID 这样随机字符串带来的页分裂问题等

当我们对该表设置了自增主键之后，则会在该表上产生一个计数器，用于为自增列分配 ID 。

自增的值并不是保存在表结构信息内的，对于不同的版本它们有如下的区别：

计数器的值存储在内存中的，重启后丢弃，下一次将读取最大的一个自增ID往后继续发号。

>

一个事务要更新一行，如果刚好有另外一个事务拥有这一行的行锁，会被锁住，进入等待状态。既然进入了等待状态，那么等到这个事务自己获取到行锁要更新数据的时候，它读到的值又是什么呢

可重复读隔离级别下，事务在启动的时候就“拍了个整个库的快照”。如果一个库有100G，那么我启动一个事务，MySQL就要拷⻉100G的数据出来，这个过程得多慢啊。但是平时事务执行起来却是非常快的。不是全部拷贝出来那是怎么实现的呢

InnoDB里面每个事务有一个唯一的事务ID，叫作transaction id。它是在事务开始的时候向InnoDB的事务系统申请的，是按申请顺序严格递增的。

而每行数据也都是有多个版本的。每次事务更新数据的时候，都会生成一个新的数据版本，并且把transaction id赋值给这个数 据版本的事务ID，记为row trx_id。同时，旧的数据版本要保留，并且在新的数据版本中，能够有信息可以直接拿到它。

数据表中的一行记录，其实可能有多个版本(row)，每个版本有自己的row trx_id。

图中虚线框里是同一行数据的4个版本，当前最新版本是V4，k的值是22，它是被transaction id 为25的事务更新的，因此它的row trx_id也是25。语句更新会生成undo log(回滚日志)，图中的三个虚线箭头，就是undo log。

按照可重复读的定义，一个事务启动的时候，能够看到所有已经提交的事务结果。但是之后，这个事务执行期间，其他事务的更新对它不可⻅。

一个事务只需要在启动的时候声明说，“以我启动的时刻为准，如果一个数据版本是在我启动之前生成的，就认;如果是我启动以后才生成的，我就不认，我必须要找到它的上一个版本”。

如果“上一个版本”也不可⻅，那就得继续往前找。如果是这个事务自己更新的数据，它自己还是要认的。

在实现上， InnoDB为每个事务构造了一个数组，用来保存这个事务启动瞬间，当前正在“活跃”的所有事务ID。“活跃”指的就 是，启动了但还没提交。数组里面事务ID的最小值记为低水位，当前系统里面已经创建过的事务ID的最大值加1记为高水位。 这个视图数组和高水位，就组成了当前事务的一致性视图(read-view)。而数据版本的可⻅性规则，就是基于数据的row trx_id和这个一致性视图的对比结果得到的。

InnoDB利用了“所有数据都有多个版本”的这个特性，实现了“秒级创建快照”的能力。

回到我们最开始的表格，看看最后执行的结果是多少。做如下假设:

事务A的视图数组就是[99,100], 事务B的视图数组是[99,100,101], 事务C的视图数组是[99,100,101,102]。为了简化分析，我先把其他干扰语句去掉，只画出跟事务A查询逻辑有关的 *** 作:

第一个有效更新是事务C，把数据从(1,1)改成了(1,2)。这时候，这个数据的最新版本的row trx_id是102，而90这个版本已经成为了历史版本。 第二个有效更新是事务B，把数据从(1,2)改成了(1,3)。这时候，这个数据的最新版本(即row trx_id)是101，而102又成为了历史版本。

事务B的update语句，如果按照一致性读，好像结果不对哦

事务B的视图数组是先生成的，之后事务C才提交，不是应该看不⻅(1,2)吗，怎么能算出(1,3)来

事务B在更新之前查询一次数据，这个查询返回的k的值确实是1。 但是，当它要去更新数据的时候，就不能再在历史版本上更新了，否则事务C的更新就丢失了。因此，事务B此时的set k=k+1是在(1,2)的基础上进行的 *** 作。 所以，这里就用到了这样一条规则:更新数据都是先读后写的，而这个读，只能读当前的值，称为 “当前读” ( current read )。

在更新的时候，当前读拿到的数据是(1,2)，更新后生成了新版本的数据(1,3)，这个新版本的row trx_id是101。

所以，在执行事务B查询语句的时候，一看自己的版本号是101，最新数据的版本号也是101，是自己的更新，可以直接使用， 所以查询得到的k的值是3。

select语句如果加锁，也是当前读。

如果把事务A的查询语句select from t where id=1修改一下，加上lock in share mode 或 for update，也都可以读到版本号是101的数据，返回的k的值是3。下面这两个select语句，就是分别加了读锁(S锁，共享锁)和写锁(X锁，排他锁)。

事务C’的不同是，更新后并没有⻢上提交，在它提交前，事务B的更新语句先发起了。前面说过了，虽然事务C’还没提交，但是(1,2)这个版本也已经生成了，并且是当前的最新版本。那么，事务B的更新语句会怎么处理呢

两阶段锁协议，事务C’没提交，也就是说(1,2)这个版本上的写锁还没释放。 而事务B是当前读，必须要读最新版本，而且必须加锁，因此就被锁住了，必须等到事务C’释放这个锁，才能继续它的当前读。

回到最初的问题，事务的可重复读的能力是怎么实现的

今天我们来看看多个事务对缓存页里的同一条数据同时进行更新或者查询，此时会产生哪些问题？这里实际会涉及到 脏写、脏读、不可重复读、幻读， 四中问题。

这个脏写的话，它的意思是说有两个事务，事务A和事务B同时在更新一条数据，事务A先把它更新为A值，事务B紧接着就把它更新为B值。事务A是先更新的，它在更新之前，这行数据的值为NULL，所以此时事务A的undo log日志大概是这样的：更新之前这行数据的值为NULL，主键为XX 。

那么此时事务B更新完了数据的值为B，结果此时事务A突然回滚了，那么就会用它的undo log日志去回滚。此时事务A一回滚，直接就会把那行数据的值更新回之前的NULL值。所以对于事务B看到的场景，就是自己明明更新了，结果值却没了，这就是 脏写。

假设事务A更新了一行数据的值为A，此时事务B去查询了一些这行数据的值，看到的值是A，然后事务B拿着刚查询到的A值去处理各种业务。但是此时不幸的事情发生了，事务A突然回滚了，导致它刚才更新的A值没了，此时那行数据的值回滚为NULL值。这就是所谓的 脏读。 它的本质是事务B去查询了事务A修改过的数据，但是此时事务A还没有提交，事务A随时会回滚导致事务B查询了一个不存在的值。

接着我们来看一下 的问题，假设我们有一个事务A开启了，在这个事务A里会多次对一条数据进行查询。然后另外有两个事务，一个是事务B，一个是事务C，它们都是对一条数据进行更新的。假设缓存页里一条数据原来的值是A值，此时事务A开启之后，第一次查询这条数据，读取到的是A值。接着事务B更新了那行数据的值为B，同时提交事务，然后事务A第二次查询该行数据，此时查到的是事务B修改过的值B 。接着事务C更新了那行数据的值为C，同时提交事务，然后事务A第三次查询该行数据，此时查到的是事务C修改过的值C值。

那么上面的场景有什么问题呢？其实要说没问题也是可以的，毕竟事务B和C都提交事务了。但是要说有问题也是可以的，就是事务A可能第一次查询到的是A值，那么它可能希望的是在事务执行期间，如果多次查询数据，都是同样的一个A值。但是该场景下，A值明显不是可重复读的。

这种情况算不算一个问题呢？其实这是根据你的业务决定的。有的业务要的是可重复读，而有的业务却需要不可重复读。

假设一个事务A先发送一条SQL语句，里面有一个条件，要查询一批数据出来，比如“select from table where id > 10”，类似这种SQL，它一开始查询出了10条数据。然后事务B往表里插入了几条数据，而且事务B还提交了。此时事务A再次查询，由于事务B插入了几条数据，导致这次它查询出来了12条数据。同样的SQL语句，两次的查询结果却不一样，所以开始怀疑自己是不是出现了幻觉？导致刚才幻读了？这就是幻读一词的由来。

在SQL标准中规定了4种事务隔离级别，就是说多个事务并发运行的时候，互相是如何隔离的，从而避免一些事务并发问题。这4种级别包括了： read uncommitted(读未提交)、read committed(读已提交)、repeatable read(可重复读)、serializable(串行化) 。

第一个read uncommitted隔离级别是不允许发生脏写的。也就是说，不可能两个事务在没提交的情况下去更新同一行数据的值，但是在这种隔离级别下，可能发生脏读、不可重复读、幻读。所以一般来说，是没有人做系统开发的时候把事务隔离级别设置为读未提交这个级别的。

第二个是read committed隔离级别，也就是俗称的RC级别，这个级别不会发生脏写和脏读。也就是说，别的事务没提交的情况下修改的值，你是绝对读不到的。但是，可能会发生不可重复读和幻读问题。

第三个是repeatable read隔离级别，也就是俗称的RR级别，就是可重复读级别。这个级别下，不会发生脏写、脏读、不可重复读的问题。事务一旦开启，多次查询一个值，会一直读到同一个值。但是它会发生幻读的问题。

最后一个隔离级别，就是serializable级别，这种级别，根本不允许多个事务并发执行，只能串行执行，所以不可能有幻读问题。但是这种级别一般除非脑子坏了，否则不可能设置这种级别。

MySQL默认设置的事务隔离级别都是RR级别的，而且MySQL的RR级别是可以避免幻读发生的。

下面的命令可以修改MySQL的默认事务隔离级别：

另外，给大家一个彩蛋，假设你在开发业务系统的时候，比如用spring里的@Transaction注解来做事务这块，假设某个事务你就是有点手痒，想搞成RC级别，那么没问题，在@Transaction注解里是有一个isolation参数的，里面是可以设置事务隔离级别的，具体的设置方式如下：

@Transaction(isolation=IsolationDEFAULT),默认的就是DEFAULT值，这个就是MySQL默认支持什么隔离就是什么隔离级别。但是你可以手动改成其它的隔离级别，比如，isolation = IsolationREAD_COMMITTED级别，此时你就可以读取到其它事务已提交的数据。

简单来说，我们每条数据其实都有两个隐藏字段，一个是trx_id，一个是roll_pointer，这个trx_id就是最近一次更新这条数据的事务id，roll_pointer就是指向了你更新这个事务之前生成的undo log，关于undo log之前都讲过了。

举个例子，假设有一个事务A（id=50），插入了一条数据，那么此时这条数据的隐藏字段以及指向的undo log如下图所示：

插入的这条数据的值是A，因为事务A的id是50，所以这条数据的trx_id就是50，roll_pointer指向一个空的undo log，因为之前这条数据是没有的。接着有一个事务B修改了一下这条数据，把值改成了B，事务B的id是58，那么此时更新之前会生成一个undo log记录之前的值，然后会让roll_pointer指向这个实际的undo log回滚日志，如下图所示：

以上就是关于MYSQL的事务隔离级别，MVCC，readView和版本链小结全部的内容，包括:MYSQL的事务隔离级别，MVCC，readView和版本链小结、mysql的事务四个特性以及事务的四个隔离级别、技术分享 | 关于 MySQL 自增 ID 的事儿等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！