共计 3298 个字符，预计需要花费 9 分钟才能阅读完成。
咱们都晓得，当多个事务并发运行的时候，很容易会产生各种各样的数据问题。如脏读，脏写，不可反复读，幻读等。
那么，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，并一直沿用上来。