咱们都晓得，当多个事务并发运行的时候，很容易会产生各种各样的数据问题。如脏读，脏写，不可反复读，幻读等。

那么，mysql是如何解决多个事务并发运行时数据的查问与更新问题的呢？

这其实就是通过Mysql的MVCC机制，而MVCC机制就是通过版本链与ReadView实现的。

事务的几种隔离级别

首先，要理解MVCC机制必须得晓得mysql事务里的几种隔离级别。

  • 读未提交
  • 读已提交
  • 可反复读
  • 串行化

读未提交: 在以后事务里，能读取到其余未提交的事务批改后的值。
会产生脏读、不可反复读、幻读。

读已提交: 在以后事务中，只能读到已提交后的事务的值。会产生不可反复读、幻读。

可反复读: 当事务开启后，在运行过程中所查问到的值是不会产生扭转的。(不会在运行过程中，因为某个值被其余事务批改并提交就读取进来)。也就是事务一旦开启，屡次查问同一个值，无论那个值在运行过程中有没有被其余事务批改并提交，你查问进去的值都是一样的。会产生幻读问题(在mysql中此事务隔离级别中通过mvcc+锁的机制把幻读也解决了)

串行化: 就是间接加锁排队串行化运行。不容许多个事务并发执行。

篇幅无限，如果对脏读，脏写，不可反复读和幻读有点不理解的能够搜搜其余文章看看

版本链

咱们都晓得，事务是能够回滚的。那么必然就要保留每次事务批改前的数据，不然到时候回滚是依据什么回滚呢？

而当你一个值被批改屡次的时候，就须要有个版本链，记录每次的值，从而才可晓得回滚到哪个对应的版本上。

而在innodb存储引擎上，汇集索引中都会蕴含两个暗藏列。一个是trx_id，用于记录事务id，一个是roll_pointer，回滚指针。

那么其实undo log 版本链看上去就大略是这个样子。

那么能够试想下以下场景：

一开始事务A(id为10)对某张表id为1的某个字段更改，把值改为A：

而后又有事务B(id为20)对那条数据进行批改，把值改成B:

最初事务C(id为30)把那条数据的值改成C:

不难看出，每次更新，都会将旧的值保存起来，放到undo log的版本链中，造成一个链表。链表的头节点就是记录最新的值。

那么此时咱们能够看到，尽管每次批改每个版本的值我都保留记录下来了，但这么多版本，我又怎么晓得我应该获取的是版本链上哪个版本的值呢？？？

这个时候就须要咱们的 ReadView 退场了。

ReadView

readview 你能够简略的了解为是一个视图。通过它，咱们能够晓得在版本链上哪个版本对于以后事务以及以后事务的隔离级别是可见的。

首先咱们要晓得readView是由什么组成的，为什么通过它咱们能够判断版本链上哪个版本是咱们应该获取的值，哪些又是不可获取的值。

那么readView的组成次要能够分为四局部：

  • m_ids: 是一个数组，记录的是以后沉闷的事务id(就是还没提交的)
  • min_trx_id: m_ids数组外面的最小值
  • max_trx_id: 示意下一个事务生成时调配给它的id。(不是m_ids外面的最大值)
  • creator_trx_id: 以后事务id

好了，在咱们晓得readview的组成后，咱们接下来能够看看在mysql中不同事务隔离级别下是怎么实现的。

如何实现

不难看出，在读未提交和串行化这两种隔离级别下，都是间接获取最新的值即可，不存在那种多版本并发管制的问题。

因而，咱们次要钻研的是在读已提交和可反复读条件下是如何通过版本链与readview获取到对应的正确版本的值。

MVCC机制

首先，咱们要晓得MVCC机制是如何通过readview和版本链就可决定对应版本链上的数据是否被读取。也就是要晓得MVCC外面外部的大抵规定是怎么的。

其实，有了这个readview，判断某个数据是否被读取，只需依照以下步骤来即可:

  • 如果被拜访版本的trx_id属性值与ReadView中的creator_trx_id值雷同，意味着以后事务在拜访它自

己批改过的记录，所以该版本能够被以后事务拜访。

  • 如果被拜访版本的trx_id属性值小于ReadView中的min_trx_id值，表明生成该版本的事务在以后事

务生成ReadView前曾经提交，所以该版本能够被以后事务拜访。

  • 如果被拜访版本的trx_id属性值大于ReadView中的max_trx_id值，表明生成该版本的事务在以后事

务生成ReadView后才开启，所以该版本不能够被以后事务拜访。

  • 如果被拜访版本的trx_id属性值在ReadView的min_trx_id和max_trx_id之间，那就须要判断一下

trx_id属性值是不是在m_ids列表中，如果在，阐明创立ReadView时生成该版本的事务还是沉闷
的，该版本不能够被拜访；如果不在，阐明创立ReadView时生成该版本的事务曾经被提交，该版
本能够被拜访。

读已提交

读已提交隔离级别下就是只能读取到其余事务曾经提交过的值，若某个值被其余事务批改了，但那个事务还未提交的时候是无奈被其余事务读取到的。

那么，这个时候咱们能够试下想以下场景：

此时，版本链上存在一条被事务id为5的插入进去的数据。且有两个沉闷事务A和B

这时候，事务B对数据进行批改，把值改成B, 那么在此时的trx_id就会变为20，同时生成一个undolog，由roll_pointer来指向。

接下来，事务A就要开始查问。这时候就要生成一个readview，不难看出，readview的m_ids为[10，20]，min_trx_id：10，max_trx_id:21（按递增为1算）,creator_trx_id:10。

那么此时，事务A去查问的时候就会发现，版本链上第一个时trx_id为20的数据，在[min_trx_id,max_trx_id)中，且也在m_ids外面。

这就证实此版本号所对应数据的事务还在沉闷状态中(还未被提交)。因而就不读取，持续顺着roll_pointer找下一条数据。

而后接下来，找到下一条数据发现trx_id=5。发现小于min_trx_id。这阐明这条数据所对应的事务在很早之前就被提交了，因而能够读取。

这个时候，事务B提交了。那依照读已提交的个性，当事务B提交的时候，事务A就应该能够读取到事务B的值，那怎么能让事务A依据MVCC机制能读取到呢？

很简略，只须要从新生成一个readview即可。从新生成readview后，这个时候readview外面的值就有:m_ids:[10],min_trx_id：10，max_trx_id:21（按递增为1算）,creator_trx_id:10。

那事务A开始查问的时候，依据MVCC机制，发现版本链上的头节点数据trx_id=20,在[min_trx_id,max_trx_id)范畴外面，且不在m_ids数组外面，因而能够读取。

因而咱们不难看出，对于读已提交这种隔离级别下的实现机制就是：每次查问都得从新生成一个readview。

可反复读(默认)

对于可反复读隔离级别下，当事务开启后，对于同一条数据，从头到尾所获取到的值都不会扭转。

一样的，咱们无妨试想下有两个事务，事务A和事务B。且有一条原始数据。

这时候，事务A开始查问，就会生成一个对应的readview，查问的时候发现trx_id<min_trx_id。证实这条数据所对应的事务在很早前就被提交了。能够读取。

而后事务B对数据批改了，把值改为20，并且还提交了！！！

这个时候就会生成一个新的节点插入到版本链中了，且trx_id为20。

那么这个时候，事务A又从新获取数据，它能查问到事务B批改并提交后的值吗？？？

不能！！！因为在可反复读隔离级别下，事务开启后就只会生成一个reaview，并且始终沿用上来。

因而当事务A再次获取的时候，会发现头节点是trx_id为20的。在[min_trx_id,max_trx_id)范畴中，但因为也在m_ids数组中，因而依据MVCC机制，不会读取这个版本的值，会持续依据roll_pointer找下一个值。并胜利读取到trx_id为5的那个版本的值。

因而不难看出，实现可反复读这种隔离级别的机制就是：在事务开启后只生成一个readview，并一直沿用上来。