【眼见为实】自己动手实践理解REPEATABLE READ && Next-Key Lock
[REPEATABLE READ]
首先设置数据库隔离级别为可重复读(REPEATABLE READ):
set global transaction isolation level REPEATABLE READ ;
set session transaction isolation level REPEATABLE READ ;
[REPEATABLE READ]能解决的问题之一
[REPEATABLE READ]隔离级别解决了不可重复读的问题,一个事务中多次读取不会出现不同的结果,保证了可重复读。
还是上一篇中模拟不可重复读的例子:
事务1:
START TRANSACTION;
① SELECT sleep(5);
② UPDATE users SET state=1 WHERE id=1;
COMMIT;
事务2:
START TRANSACTION;
① SELECT * FROM users WHERE id=1;
② SELECT sleep(10);
③ SELECT * FROM users WHERE id=1;
COMMIT;
事务1先于事务2执行。
事务1的执行信息:
[SQL 1]START TRANSACTION;
受影响的行: 0
时间: 0.000s
[SQL 2]
SELECT sleep(5);
受影响的行: 0
时间: 5.001s
[SQL 3]
UPDATE users SET state=1 WHERE id=1;
受影响的行: 1
时间: 0.000s
[SQL 4]
COMMIT;
受影响的行: 0
时间: 0.062s
事务2的执行信息:
[SQL 1]
SELECT * FROM users WHERE id=1;
受影响的行: 0
时间: 0.000s
[SQL 2]
SELECT sleep(10);
受影响的行: 0
时间: 10.001s
[SQL 3]
SELECT * FROM users WHERE id=1;
受影响的行: 0
时间: 0.001s
[SQL 4]
COMMIT;
受影响的行: 0
时间: 0.001s
执行结果:
结论:
可重复读[REPEATABLE READ]隔离级别解决了不可重复读的问题。
分析:
可重复读[REPEATABLE READ]隔离级别能解决不可重复读根本原因其实就是前文讲过的read view的生成机制和[READ COMMITTED]不同。
[READ COMMITTED]:只要是当前语句执行前已经提交的数据都是可见的。
[REPEATABLE READ]:只要是当前事务执行前已经提交的数据都是可见的。
在[REPEATABLE READ]的隔离级别下,创建事务的时候,就生成了当前的global read view,一直维持到事务结束。这样就能实现可重复读。
在模拟不可重复读的事务中,事务2创建时,会生成一份read view。事务1的事务id trx_id1=1,事务2的事务id trx_id2=2。假设事务2第一次读取数据前的此行数据的事务trx_id=0。事务2中语句①执行前生成的read view为{1},trx_id_min=1,trx_id_max=1。因为trx_id(0)<trx_id_min(1),该行记录的当前值可见,将该可见行的值state=0返回。因为在[REPEATABLE READ]隔离级别下,只有在事务创建时才会重新生成read view ,事务2第二次读取数据之前事务1对数据进行了更新操作,此行数据的事务trx_id=1。trx_id_min(1)=trx_id(1)=trx_id_max(1),此时此行数据对事务2是不可见的,从该行记录的DB_ROLL_PTR指针所指向的回滚段中取出最新的undo-log的版本号的数据,将该可见行的值state=0返回。所以事务2第二次读取数据时的处理和第一次读取时是一致的,读取的state=0。数据是可重复读的。
从事务1的执行信息中的[SQL 3]我们可以得知,[REPEATABLE READ]隔离级别读操作也是不加锁的。因为如果读需要加S锁的话,是在事务结束时释放S锁的。那么事务1[SQL 3]进行更新操作申请X锁的时候便会等待事务2的S锁释放。现实并不是。
我们知道,MySql的InnoDB引擎是通过MVCC的方式在保证数据的安全性的同时,实现了读的非阻塞。MVCC模式需要额外的存储空间,需要做更多的行检查工作;但是保证了读操作不用加锁,提升了性能,是一种典型的牺牲空间换取时间思想的实现。需要注意的是,MVCC只在[READ COMMITTED]和[REPEATABLE READ]两个隔离级别下工作。其他两个隔离级别都和MVCC不兼容,因为[READ UNCOMMITTED]总是读取最新的数据行,而不是符合当前事务版本的数据行。而[SERIALIZABLE]则会对所有读取的行都加锁。
通过亲自实践模拟分析[READ COMMITTED]和[REPEATABLE READ]两个隔离级别的工作机制,我们也能深刻的体会到各个数据库引擎实现各种隔离级别的方式并不是和标准sql中的封锁协议定义一一对应的。
[REPEATABLE READ]能解决的问题之二
幻读其实是不可重复读的一种特殊情况。不可重复读是对数据的修改更新产生的;而幻读是插入或删除数据产生的。所谓的幻读有2种情况,一个事物之前读的时候,读到一条记录,再读发现记录没有了,被其它事务删了,另外一种是之前读的时候记录不存在,再读发现又有这条记录,其它事物插入了一条记录。
事务1:
START TRANSACTION;
SELECT * FROM users;
SELECT sleep(10);
SELECT * FROM users;
COMMIT;
事务2:
START TRANSACTION;
SELECT sleep(5);
INSERT INTO users VALUES(2,'song',2);
COMMIT;
执行结果:
1.预期结果
2.实际结果
事务1中并没有读取到事务2新插入的数据,并没有发生幻读现象。这有点出乎我的意料,难道Mysql[REPEATABLE READ]隔离级别能解决幻读问题?按照封锁协议定义,三级封锁协议是解决不了幻读的问题的。只有最强封锁协议,读和写都对整个表加锁,才能解决幻读的问题。但是这样做相当于所有的操作串行化,数据库支持并发的能力会变得极差。所以Mysql的InnoDB引擎通过自己的方式在[REPEATABLE READ]隔离级别上解决了幻读的问题,下面我们探究一下InnoDB引擎是如何解决幻读问题的。
分析:
InnoDB有三种行锁的算法:
1.Record Lock:单个行记录上的锁。
2.Gap Lock:间隙锁,锁定一个范围,但不包括记录本身。GAP锁的目的,是为了防止同一事务的两次当前读,出现幻读的情况。
3.Next-Key Lock:1+2,锁定一个范围,并且锁定记录本身。主要目的是解决幻读的问题。
在[REPEATABLE READ]级别下,如果查询条件能使用上唯一索引,或者是一个唯一的查询条件,那么仅加行锁(通过唯一的查询条件查询唯一行,当然不会出现幻读的现象);如果是一个范围查询,那么就会给这个范围加上 Gap锁或者 Next-Key锁 (行锁+Gap锁)。理论上不会发生幻读。
验证一下Gap Lock和Next-Key Lock的存在
我们可以通过自己操作来验证一下Gap Lock和Next-Key Lock的存在。
首先我们需要给state字段加上索引。然后准备几条数据,如下图:
事务1:
START TRANSACTION;
① SELECT * FROM users WHERE state=3 for UPDATE;
事务2:
[SQL]INSERT INTO users VALUES(5,'song',1);
[Err] 1205 - Lock wait timeout exceeded; try restarting transaction
[SQL]INSERT INTO users VALUES(6,'song',2);
[Err] 1205 - Lock wait timeout exceeded; try restarting transaction
[SQL]INSERT INTO users VALUES(6,'song',3);
[Err] 1205 - Lock wait timeout exceeded; try restarting transaction
[SQL]INSERT INTO users VALUES(6,'song',4);
[Err] 1205 - Lock wait timeout exceeded; try restarting transaction
[SQL]INSERT INTO users VALUES(5,'song',0);
受影响的行: 1
时间: 0.120s
[SQL]INSERT INTO users VALUES(6,'song',5);
受影响的行: 1
时间: 0.195s
[SQL]INSERT INTO users VALUES(7,'song',7);
受影响的行: 1
时间: 0.041s
因为InnoDB对于行的查询都是采用了Next-Key Lock的算法,锁定的不是单个值,而是一个范围(GAP)。上面索引值有1,3,5,8,其记录的GAP的区间如下:
(-∞,1],(1,3],(3,5],(5,8],(8,+∞)。是一个左开右闭的空间。需要注意的是,InnoDB存储引擎还会对辅助索引下一个键值加上Gap Lock。事务1语句①锁定的范围是(1,3],下个键值范围是(3,5],所以插入1~4之间的值的时候都会被锁定,要求等待,等待超过一定时间便会进行超时处理(Mysql默认的超时时间为50秒)。插入非这个范围内的值都正常。
[REPEATABLE READ]读到底加不加锁?
当我理解了[REPEATABLE READ]隔离级别是如何解决幻读问题时,随即产生了另一个疑问。[READ COMMITED]和[REPEATABLE READ]通过MVCC的方式避免了读操作加锁的问题,但是[REPEATABLE READ]又为了解决幻读的问题加Gap Lock或Next-Key Lock。那么问题来了,[REPEATABLE READ]读到底加不加锁?我对这个问题是百思不得其解,直到读到了这篇文章才算理解了一些。
我们可以思考一下如果InnoDB对普通的查询也加了锁,那和序列化(SERIALIZABLE)的区别又在哪里呢?我的理解是InnoDB提供了Next-Key Lock,但需要应用自己去加锁。这里又涉及到一致性读(快照读)和当前读。如果我们选择一致性读,也就是MVCC的模式,读就不需要加锁,读到的数据是通过Read View控制的。如果我们选择当前读,读是需要加锁的,也就是Next-Key Lock,其他的写操作需要等待Next-Key Lock释放才可写入,这种方式读取的数据是实时的。
一致性读很好理解,读不加锁,不堵塞读。当前读对读加锁可能比较难理解,我们可以通过一个例子来理解一下:
事务1 事务2
START TRANSACTION; START TRANSACTION;
SELECT * FROM users;
INSERT INTO users VALUES (2, 'swj',2);
COMMIT;
SELECT * FROM users;
SELECT * FROM users LOCK IN SHARE MODE;
SELECT * FROM users FOR UPDATE;
执行结果:
mysql> SELECT * FROM users;
+----+------+-------+
| id | name | state |
+----+------+-------+
| 1 | swj | 1 |
+----+------+-------+
1 row in set (0.04 sec)
mysql> SELECT * FROM users;
+----+------+-------+
| id | name | state |
+----+------+-------+
| 1 | swj | 1 |
+----+------+-------+
1 row in set (0.08 sec)
mysql> SELECT * FROM users LOCK IN SHARE MODE;
+----+------+-------+
| id | name | state |
+----+------+-------+
| 1 | swj | 1 |
| 2 | swj | 2 |
+----+------+-------+
2 rows in set (0.00 sec)
mysql> SELECT * FROM users FOR UPDATE;
+----+------+-------+
| id | name | state |
+----+------+-------+
| 1 | swj | 1 |
| 2 | swj | 2 |
+----+------+-------+
2 rows in set (0.00 sec)
结论:MVCC是实现的是快照读,Next-Key Lock是对当前读。MySQL InnoDB的可重复读并不保证避免幻读,需要应用使用加锁读来保证,而这个加锁读使用到的机制就是Next-Key Lock。
本文为博主学习感悟总结,水平有限,如果不当,欢迎指正。
如果您认为还不错,不妨点击一下下方的[【推荐】](javascript:void(0)
【眼见为实】自己动手实践理解REPEATABLE READ && Next-Key Lock的更多相关文章
- 【眼见为实】自己动手实践理解数据库REPEATABLE READ && Next-Key Lock
[REPEATABLE READ] 首先设置数据库隔离级别为可重复读(REPEATABLE READ): set global transaction isolation level REPEATAB ...
- 【眼见为实】自己动手实践理解数据库READ UNCOMMITED && SERIALIZABLE
目录 准备工作 ①准备测试表和测试数据 ②关闭数据库事务自动提交 ③设置InnoDB存储引擎隔离级别 [READ UNCOMMITTED] [READ UNCOMMITTED]能解决的问题 [READ ...
- 【眼见为实】自己动手实践理解READ COMMITTED && MVCC
[眼见为实]自己动手实践理解 READ COMMITTED && MVCC 首先设置数据库隔离级别为读已提交(READ COMMITTED): set global transacti ...
- 【眼见为实】自己动手实践理解数据库READ COMMITTED && MVCC
[READ COMMITTED] 首先设置数据库隔离级别为读已提交(READ COMMITTED): set global transaction isolation level READ COMMI ...
- 【原创 Hadoop&Spark 动手实践 8】Spark 应用经验、调优与动手实践
[原创 Hadoop&Spark 动手实践 7]Spark 应用经验.调优与动手实践 目标: 1. 了解Spark 应用经验与调优的理论与方法,如果遇到Spark调优的事情,有理论思考框架. ...
- 【原创 Hadoop&Spark 动手实践 9】Spark SQL 程序设计基础与动手实践(上)
[原创 Hadoop&Spark 动手实践 9]SparkSQL程序设计基础与动手实践(上) 目标: 1. 理解Spark SQL最基础的原理 2. 可以使用Spark SQL完成一些简单的数 ...
- 【原创 Hadoop&Spark 动手实践 10】Spark SQL 程序设计基础与动手实践(下)
[原创 Hadoop&Spark 动手实践 10]Spark SQL 程序设计基础与动手实践(下) 目标: 1. 深入理解Spark SQL 程序设计的原理 2. 通过简单的命令来验证Spar ...
- 【原创 Hadoop&Spark 动手实践 6】Spark 编程实例与案例演示
[原创 Hadoop&Spark 动手实践 6]Spark 编程实例与案例演示 Spark 编程实例和简易电影分析系统的编写 目标: 1. 掌握理论:了解Spark编程的理论基础 2. 搭建 ...
- 【原创 Hadoop&Spark 动手实践 7】Spark 计算引擎剖析与动手实践
[原创 Hadoop&Spark 动手实践 7]Spark计算引擎剖析与动手实践 目标: 1. 理解Spark计算引擎的理论知识 2. 动手实践更深入的理解Spark计算引擎的细节 3. 通过 ...
随机推荐
- 一句Python,一句R︱numpy、array——高级matrix
先学了R,最近刚刚上手python,所以想着将python和R结合起来互相对比来更好理解python.最好就是一句python,对应写一句R. python中的numpy模块相当于R中的matirx矩 ...
- 进程中调用CreateMutex
// TestStorage.cpp : 定义控制台应用程序的入口点. // #include "stdafx.h" #include <Windows.h> #inc ...
- Windows PE入门基础知识:Windows PE的作用、命名规则、启动方式、启动原理
Windows PE的全名是WindowsPreinstallationEnvironment(WinPE)直接从字面上翻译就 是"Windows预安装环境".微软的本意是:Win ...
- Netty未来展望
作为<Netty权威指南(第2版)>的结尾章节,和读者朋友们一起展望下Netty的未来. 1应用范围 随着大数据.互联网和云计算的发展,传统的垂直架构逐渐将被分布式.弹性伸缩的新架构替代. ...
- jquery-1.11.1.js
每次想要使用这个js时,总是要到官网上下载,太麻烦,现在把它收录了 jquery-1.11.1.js /*! * jQuery JavaScript Library v1.11.1 * http ...
- 芝麻HTTP:Appium的安装
Appium是移动端的自动化测试工具,类似于前面所说的Selenium,利用它可以驱动Android.iOS等设备完成自动化测试,比如模拟点击.滑动.输入等操作,其官方网站为:http://appiu ...
- 如何高效的使用PowerShell备份数据库
初始脚本 Get-SqlDatabase -ServerInstance localhost | Where { $_.Name -ne 'tempdb' } | Backup-SqlDatabase ...
- Excle巧取汉字打头的字串内容
处理表格数据时遇到问题:从网页表格中复制来的数据,地址一列中出现类似于“4AWZCX万载老林业局2”的无用字符前缀.现在希望提取第一个汉字及其之后的所有内容(图1),寻求高效分离中英文及数字的实操方法 ...
- 细说Ajax跨域
一.什么是跨域 跨域问题来自于浏览器同源策略的限制,包括DOM同源限制和Ajax同源限制,本文探讨的是Ajax跨域.Ajax跨域指的是一个页面的Ajax只能请求和当前页面同源的数据,如果发现请求到的数 ...
- 慢慢人生路,学点Jakarta基础-JavaDoc标记
本文对使用Maven工程构建Jenkinsjob时遇到的问题进行一下分析汇总. JavaDoc标记使用问题 一般Maven项目都有配置产生Java DOC,但是在Jenkins里面产生DOC会有一些严 ...