原文作者：小小一只鸟

原文标题：mysql面试题MVCC原理事务隔离级别

发布时间：2021-01-19 19:43:38

mysql事务隔离级别可重复读面试题

熊大

话说今天漂亮的妹子给我发过一张图如下!

前提:

> 这是InnoDB引擎下的默认隔离级别。

> 我们知道InnoDB默认的级别是rr也就是可`重复读`

在看这个值之前我们先了解个概念什么是MVCC

MVCC多版本并发控制指的是 “维持一个数据的多个版本，使得读写操作没有冲突” 。

而快照读就是MySQL为我们实现MVCC理想模型的其中一个具体非阻塞读功能。而相对而言，当前读就是悲观锁的具体功能实现。

快照”在 MVCC 里是怎么工作的:

在可重复读隔离级别下，事务在启动的时候就“拍了个快照”。这个快照是基于整库的。当然它并不是把所有数据都拷贝出来得。

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

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

InnoBB也是利用每个数据有多个版本得特性(其实是记住了row_trx_id)实现了秒级快照读得能力。

在事务隔离级别得时候我们曾经谈过可重复读的隔离级别

在我的事务执行中我对别的一切视而不见给我一百万也不要。

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

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

同时InnoDB 为每个事务构造了一个数组，用来保存这个事务启动瞬间，当前正在“活跃”的所有事务 ID。“活跃”指的就是，启动了但还没提交

那么上图中就会有三个事务产生他们的事务id数组分别如下：

此时事务A在事务B、事务C之前也就是说 相对于事务A而言事务B、事务C是不可见的这也符合可重复读的定义因此Q2值为18。

那么Q1呢？

在事务B之后执行了事务C 看图所示事务C执行了更新语句。 那么大家不知道对二阶段提交是否有印象

一条更新语句得流程也就是二阶段提交如果忘记请点开这篇文章加深一下记忆二阶段提交

说这个得主要意思就是update语句会默认提交

update语句其实在执行期间会申请锁(行锁)

假如不申请锁会出现什么情况？

> 假设我们数据库有一条记录初始值是1,在并发得环境下对同一条数据更新

> 第一次加1, 第二次也加1。

>那么很有可能他们查询出得值是一样得然后更新

>最后发现结果是2,那么这个结果我们肯定接受不了得。

当然行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。这个就是两阶段锁协议。

并且更新数据都是先读后写的，而这个读，只能读当前的值，称为“当前读”(current read)。

> 那么我们在看下由于事务C执行了update 也就是当前读 所以这个时候age

> 已经改成了19当然如果我们手动提交事务如果事务C迟迟不提交

> 那么事务B的的update语句会等到事务C释放再去执行。

那么我们返回来看事务B

> 事务B在第一次查询的时候age毫无疑问是18的 然后跟新通过上面得知update

> 语句加锁并且是当前读那么这个时候age变成了20。

> 在执行事务 B 查询语句的时候，一看自己的版本号是 2,最新数据的版本号

> 也是 2,是自己的更新，可以直接使用，所以查询得到的 age 的值是 20。

>

Post Views:

10