这篇我觉得有点难度,我会更慢的更详细的分析一些 case 。

MySQL 的默认事务隔离级别和其他几个主流数据库隔离级别不同,他的事务隔离级别是 RR(REPEATABLE-READ) 其他的主流数据库比如 oracle 通常是 RC(READ-COMMITTED)

关于数据库有哪些隔离级别我这里就不详细阐述了,大概是什么特性我这里就不阐述了大家可以自行翻阅资料,让我们聚焦这两个最重要的隔离级别在一些查询更新的时候会出现什么样的特性表达。

当我们使用 RR 的时候,事务启动的时候会创建一个视图 read-view,之后事务执行期间,即使有其他事务修改了数据,事务看到的仍然和她启动的时候看到的一样。也就是说,一个在可重复读隔离级别下执行的事务不受外界影响。

但是上一篇分享锁的文章里面我们也提到了,如果说另外一个事务对表加了行锁,他会被锁住进入等待状态。那么当等待状态结束,这个事务自己要获取行锁更新数据的时候,他读到的值是什么呢?

来看个例子

mysql> CREATE TABLE `t` (
`id` int(11) NOT NULL,
`k` int(11) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB;
insert into t(id, k) values(1,1),(2,2);

然后使用这个事务启动顺序来测试

这里有几个点需要注意,我们在数据库使用事务 begin/start transaction 命令并不是一个事务的起点,在执行到第一个操作 InnooDB 表的语句,事务才被真正启动。

如果我们要马上启动一个一致性读事务使用 start transaction with consistent snapshot 这个。

它的含义是:执行 start transaction 同时建立本事务一致性读的 snapshot . 而不是等到执行第一条语句时,才开始事务,并且建立一致性读的 snapshot 。

文章中说,这个顺序查询,事务 B 查询到的 id =1 的 k 值是3,事务 A 查询到的值 k 值是 1。我起初也无法理解,下面让我们一步一步来得出结论。

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

在可重复读隔离级别下,事务在启动的时候就拍了快照。InnoDB 里面每个事务有一个唯一的事务 ID, 叫 transaction id。它是在事务开始的时候向 InnoDB 的事务系统申请的。是按照申请顺序递增的。每行数据也有多个版本,每次事务更新数据的时候,都会生成一个新的数据版本,并且把 transaction id 赋值给这个数据版本的事务 ID, row trx_id。旧的数据版本要保留,并且新的数据版本中,能够有信息可以直接拿到。

当前最新版本是 V4 V4 版本是经过一系列更新之后得到的最新的状态。 他的 row trx_id = 25。

u1 u2 u3 都是 undo log 的记录,我们可以在 v4 通过 undolog 恢复到版本v1 v2 v3 并不是物理上真实存在的。

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

因此一个在 RR 事务级别启动一个事务的时候声明说,以我启动的时刻为准,如果一个数据版本是在我启动之前生成的就认,如果是我启动之后才生成的,就不认,我必须找到他的上一个版本。如果上一个版本也不可见,就继续往前找。当然如果是这个事务自己本身更新的数据,它自己是要认的。

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

这个数组组成了一个类似这样的东西

低水位:指获取到这个数组内的 trx_id 最小值。

高水位:指获取到的这个数组内的 trx_id 最大值 + 1

这样对于当前事务启动的瞬间来说,一个数据版本的 row trx_id 有以下几种可能。

1. 如果落在绿色部分,标示这个版本是已经提价的事务护着当前自己事务生成的,这个数据是可见的。

2. 如果落在红色部分,标示这个版本是由将来的事务生成的,是不可见的。

3. 如果落在黄色部分,

a. 如果 row trx_id 在数组中,标示这个版本是由还没有提交哦的事务生成的,不可见。

b. 如果 row trx_id 不在数组中,标示这个版本是已经提交了的事务生成的,可见。

下面我们用上面的理论拉来解释一下为什么我第一张图的查询结果会是那个样子。

1. 假设 事务 A 开始前,系统里面没有哦活跃事务 ID .

2. 事务 A 开始时候的事务版本号为 100 事务 B 开始时候的事务版本号为 101 事务 C 开始时候的事务版本号为 102。

3. 三个事务开始前 id =1 k =1 的数据 row trx_id 是 90.

事务 A 开始的时候事务数组为 [100]

事务 B 开始时候的事务数组为 [100, 101]

事务 C 开始时候的事务数组为 [100, 101, 102]

祖先版本是 id =1, k=2 对应版本是 90。

第一个有效更新的事务是 C 当 C 完成更新之后 102 版本就是对应 id = 1 k = 2.

这个时候由于版本 102 无论对于事务 B 还是 事务 A 都处于高水位,所以都是不见的。也就是说现在我们执行

select * from t where id = 1 会发现

mysql> select * from t;
+----+------+
| id | k |
+----+------+
| 1 | 1 |
| 2 | 2 |
+----+------+

这个时候第二个有效事务 B 更新了,把数据从 id =1 k = 2 变更为 id =1 k=3,这个时候数据的最新版本变成了 101,而102 变成了历史版本。

注意这个时候事务 B 会发现自己的数据没有经过 k=2 这一步 直接就变成 k =3 了。。。因为事务 C 更新并且提交了,我们在这个基础上增加会读取到 102 的更新。

但是事务 A 还是无法读取到 102 版本和 101 版本的更新,因为他们都在高水位,所以最终读取到的还是 id =1 k=1。

但是真实的情况 事务 A 是会去判断的,也就是说他会找到最后一个被更新的版本 101 会发现是高水位不可见。

接着找上一个版本 102 还是高水位不可见。

最后找到原始版本 90 处于低于低水位的区域可见。

这样执行下来,虽然期间这一行数据被修改过,但是事务 A 无论在什么时候查询,看到这行数据的结果都是一致的,所以我们称为一致性读。

RR 的更新数据都是先读后写的,这个读就是当前读。这可以解释为什么我们可以跳过 k=2 直接 k=3。因为在 k=1 的时候进行当前读发现 k=2 了,然后再 +1 就 k=3 了。

当然 select xx for update | lock in share mode 也是当前读。

我觉得 此片文章到此就差不多了。感觉老师后面以紧接着介绍了一些无关紧要的东西 包括 RC 的情况。给本来就比较难以理解的情况搞得更复杂了。

现在我解除到大部分公司的 DB 使用 MySQL 都会将事务隔离级别从默认的 RR 设置到 RC,更好理解也可以更方便的用乐观锁来保证数据的一致性。并且我感觉如果不使用当前读,可能还会对性能有一定的影响。毕竟上面介绍到的流程里面,是需要扫 undolog 参与的,感觉这些可能都会有一定的性能损失。

Reference:

本读书笔记皆来自发布在极客时间的 林晓斌(丁奇)的 MySQL 实战45讲:

极客时间版权所有: https://time.geekbang.org/ 版权所有:

https://time.geekbang.org/column/article/70562

【MySQL 读书笔记】RR(REPEATABLE-READ)事务隔离详解的更多相关文章

  1. Net Core中数据库事务隔离详解——以Dapper和Mysql为例

    Net Core中数据库事务隔离详解--以Dapper和Mysql为例 事务隔离级别 准备工作 Read uncommitted 读未提交 Read committed 读取提交内容 Repeatab ...

  2. MySQL提升笔记(3)日志文件详解

    在MySQL数据库和InnoDB存储引擎中,有很多种文件,如:参数文件.日志文件.socket文件.pid文件.MySQL表结构文件.存储引擎文件. 本节重点关注日志文件,MySQL的复制.事务等重要 ...

  3. Windows驱动——读书笔记《Windows驱动开发技术详解》

    =================================版权声明================================= 版权声明:原创文章 谢绝转载  请通过右侧公告中的“联系邮 ...

  4. (转)Spring事务管理详解

    背景:之前一直在学习数据库中的相关事务,而忽略了spring中的事务配置,在阿里面试时候基本是惨败,这里做一个总结. 可能是最漂亮的Spring事务管理详解 https://github.com/Sn ...

  5. 【Spring】——声明式事务配置详解

    项目中用到了spring的事务: @Transactional(rollbackFor = Exception.class, transactionManager = "zebraTrans ...

  6. 可能是最漂亮的Spring事务管理详解

    Java面试通关手册(Java学习指南):https://github.com/Snailclimb/Java_Guide 微信阅读地址链接:可能是最漂亮的Spring事务管理详解 事务概念回顾 什么 ...

  7. 可能是最漂亮的Spring事务管理详解 专题

    微信阅读地址链接:可能是最漂亮的Spring事务管理详解 事务概念回顾 什么是事务? 事务是逻辑上的一组操作,要么都执行,要么都不执行. 事物的特性(ACID): 原子性: 事务是最小的执行单位,不允 ...

  8. 最漂亮的Spring事务管理详解

    SnailClimb 2018年05月21日阅读 7245 可能是最漂亮的Spring事务管理详解 Java面试通关手册(Java学习指南):github.com/Snailclimb/- 微信阅读地 ...

  9. Redis的事务功能详解

    Redis的事务功能详解 MULTI.EXEC.DISCARD和WATCH命令是Redis事务功能的基础.Redis事务允许在一次单独的步骤中执行一组命令,并且可以保证如下两个重要事项: >Re ...

随机推荐

  1. springboot~@Valid注解对嵌套类型的校验

    @Valid注解可以实现数据的验证,你可以定义实体,在实体的属性上添加校验规则,而在API接收数据时添加@valid关键字,这时你的实体将会开启一个校验的功能,具体的代码如下,是最基本的应用: 实体: ...

  2. Spring Boot 2.x 系列教程:WebFlux 系列教程大纲(一)

    摘要: 原创出处 https://www.bysocket.com 「公众号:泥瓦匠BYSocket 」欢迎关注和转载,保留摘要,谢谢! WebFlux 系列教程大纲 一.背景 大家都知道,Sprin ...

  3. .NET ClrProfiler ILRewrite 商业级APM原理

    Demo:https://github.com/caozhiyuan/ClrProfiler.Trace 背景 为了实现自动.无依赖地跟踪分析应用程序性能(达到商业级APM效果),作者希望能动态修改应 ...

  4. 第64章 学习 - Identity Server 4 中文文档(v1.0.0)

    以下是一些在线,远程和课堂培训选项,以了解有关ASP.NET Core Identity和IdentityServer4的更多信息. 64.1 现代应用程序的身份和访问控制(使用ASP.NET Cor ...

  5. javascript小记五则:用JS写一个图片左右自由滚动的“跑马灯”效果

    之前看了很多百度搜索出的东西,十个有九个是不能实用的,个个讲的都不详细,今天详细给大家讲解下关于这个图片“跑马灯”滚动效果,源码如下: <!DOCTYPE html PUBLIC "- ...

  6. 第三章:shiro授权认证

    授权:也叫访问控制,即在应用中控制谁能访问哪些资源(如访问页面/编辑数据/页面操作等). 主体:即访问应用的用户,在Shiro中使用Subject代表该用户.用户只有授权后才允许访问相应的资源. 资源 ...

  7. 【学习笔记】分布式Tensorflow

    目录 分布式原理 单机多卡 多机多卡(分布式) 分布式的架构 节点之间的关系 分布式的模式 数据并行 同步更新和异步更新 分布式API 分布式案例 Tensorflow的一个特色就是分布式计算.分布式 ...

  8. Java学习点滴——Integer缓存

    前言 一切从下面这段代码开始 public static void test(String[] agrs){ Integer a = 1; Integer b = 2; System.out.prin ...

  9. 设计模式 - 单例模式(Singleton Pattern)

    单例模式 介绍 模式:创建型 意图:保证一个类只有一个实例,并提供一个访问它的全局访问点 解决:一个全局使用的类频繁地创建与销毁 场景: 唯一序列号 web中的计数器 I/O与数据库的连接 …… 实现 ...

  10. K3日志定时备份

    K3日志超过5万条以后,每次用户登陆后,系统都会提示日志太多.但是日志又不能随意删除,所以需要做个数据库定时任务,定时把日志转移到备份表. declare @dt datetime;; SELECT ...