脏读、幻读和不可重复读

1、引言

脏读、不可重复读和幻读是数据库中因为并发访问致使的数据读取问题。当多个事务同时进行时能够经过修改数据库事务的隔离级别来处理这三个问题。数据库

2、问题解释

一、脏读(读取未提交的数据)

脏读又称无效数据的读出,是指在数据库访问中,事务 A 对一个值作修改,事务 B 读取这个值,可是因为某种缘由事务 A 回滚撤销了对这个值得修改,这就致使事务 B 读取到的值是无效数据。并发

二、不可重复读(先后数据屡次读取,结果集内容不一致)

不可重复读即当事务 A 按照查询条件获得了一个结果集,这时事务 B 对事务 A 查询的结果集数据作了修改操做,以后事务 A 为了数据校验继续按照以前的查询条件获得的结果集与前一次查询不一样,致使不可重复读取原始数据。性能

三、幻读(先后数据屡次读取,结果集数量不一致)

幻读是指当事务 A 按照查询条件获得了一个结果集,这时事务 B 对事务 A 查询的结果集数据作新增操做,以后事务 A 继续按照以前的查询条件获得的结果集无缘无故多了几条数据,好像出现了幻觉同样。spa

3、事务隔离

在并发条件下会出现上述问题,如何着手解决他们保证咱们程序运行的正确性是很是重要的。数据库提供了 Read uncommitted 、Read committed 、Repeatable read 、Serializable 四种事务隔离级别来解决脏读、幻读和不可重复读问题,同时容易想到,能够经过加锁的方式实现事务隔离。.net

在数据库的增删改查操做中,insert 、delete 、update 都会加排他锁,排它锁会阻止其余事务对其加锁的数据加任何类型的锁。而 select 只有显示声明才会加锁。code

  • Read uncommitted对象

    读未提交,说的是一个事务能够读取到另外一个事务未提交的数据修改。

    读若不显式声明是不加锁的,能够直接读取到另外一个事务对数据的操做,没有避免脏读、不可重复读、幻读。blog

  • Read committed索引

    读已提交,说的是一个事务只能读取到另外一个事务已经提交的数据修改。

    很明显,这种隔离级别避免了脏读,可是可能会出现不可重复读、幻读。生命周期

  • Repeatable read

    可重复读,保证了同一事务下屡次读取相同的数据返回的结果集是同样的。

    这种隔离级别解决了脏读和不可重复读问题,可是扔有可能出现幻读。

  • Serializable

    串行化,对同一数据的读写全加锁,即对同一数据的读写全是互斥了,数据可靠行很强,可是并发性能不忍直视。

    这种隔离级别虽然解决了上述三个问题,可是牺牲了性能。

总结以下表: √ 表明可能出现,× 表明不会出现。

隔离级别 脏读 不可重复读 幻读
Read uncommitted
Read committed ×
Repeatable read × ×
Serializable × × ×

4、MySQL 事务隔离级别的实现

在 MySQL 中只有 InnoDB 存储引擎支持事务,可是在平常使用 MySQL 时咱们好像没有怎么关心过上述三个问题啊...

缘由很简单,MySQL 默认 Repeatable read 隔离级别,使用了 MVCC 技术,而且解决了幻读问题。

MVCC


MVCC 全名多版本并发控制,使用它能够保证 InnoDB 存储引擎下读操做的一致性。使用 MVCC 能够查询被另外一个事务修改的行数据,而且能够查看这些行被更新以前的数据,值得注意的是使用 MVCC 增长了多事务的并发性能,可是并无解决幻读问题

一、原理

MVCC 是经过保存数据在某个时间点的快照来实现的。也就是说在同一个事务的生命周期中,数据的快照始终是相同的;而在多个事务中,因为事务的时间点极可能不相同,数据的快照也不尽相同。

二、实现细节

  • 每行数据都存在一个版本,每次数据更新时都更新该版本。
  • 修改时Copy出当前版本随意修改,各个事务之间互不干扰。
  • 保存时比较版本号,若是成功(commit),则覆盖原记录;失败则放弃copy(rollback)。

经过上面特色咱们能够看出,MVCC 其实就是相似乐观锁的一种实现。

三、InnoDB 中 MVCC 实现

在 InnoDB 中为每行增长两个隐藏的字段,分别是该行数据建立时的版本号删除时的版本号,这里的版本号是系统版本号(能够简单理解为事务的 ID),每开始一个新的事务,系统版本号就自动递增,做为事务的 ID 。一般这两个版本号分别叫作建立时间和删除时间。

下面经过具体的例子来帮助理解 InnoDB 中 MVCC 实现,

首先建立一个表:

create table info( 
id int primary key auto_increment, 
name varchar(20));

INSERT
InnoDB 为新插入的每一行保存当前系统版本号做为版本号。如今假设事务的版本号从 1 开始。

第一个事务 ID为1;

start transaction;
insert into info values(NULL,'a');
insert into info values(NULL,'b');
insert into info values(NULL,'c');
commit;

对应在数据中的表以下(后面两列是隐藏列,也就是版本号)

id name 建立版本(事务ID) 删除版本(事务ID)
1 a 1 undefined
2 b 1 undefined
3 c 1 undefined
SELECT

InnoDB 会根据下面两个条件检查每行记录:

  • 只会查找版本早于当前事务版本的数据行(行的系统版本号小于或等于事务的系统版本号),这样能够确保事务读取的行,要么是在事务开始前已经存在的,要么是事务自身插入或者修改过的
  • 行的删除版本要么未定义,要么大于当前事务版本号,这能够确保事务读取到的行,在事务开始以前未被删除

只有 a, b 同时知足的记录,才能返回做为查询结果.


DELETE

InnoDB会为删除的每一行保存当前系统的版本号(事务的ID)做为删除标识.
看下面的具体例子分析:

第二个事务 ID为2;

start transaction;
select * from info;  //(1)
select * from info;  //(2)
commit;
  • 假设1
    假设在执行这个事务 ID 为 2 的过程当中,刚执行到 (1) ,这时,有另外一个事务 ID 为 3 往这个表里插入了一条数据;

第三个事务ID为3;

start transaction;
insert into info values(NULL,'d');
commit;

这时表中的数据以下:

id name 建立版本(事务ID) 删除版本(事务ID)
1 a 1 undefined
2 b 1 undefined
3 c 1 undefined
4 d 3 undefined

而后接着执行 事务2 中的 (2) ,因为 id=4 的数据的建立时间(事务 ID 为 3 ),执行当前事务的 ID 为 2 ,而 InnoDB 只会查找事务 ID 小于等于当前事务 ID 的数据行,因此 id=4 的数据行并不会在执行 事务2 中的 (2) 被检索出来,在 *事务2 *中的两条 select 语句检索出来的数据都只会以下表:

id name 建立版本(事务ID) 删除版本(事务ID)
1 a 1 undefined
2 b 1 undefined
3 c 1 undefined
  • 假设2
    假设在执行这个事务 ID 为 2 的过程当中,刚执行到 (1) ,假设事务执行完 事务3 后,接着又执行了 事务4 ;

第四个事务:

start   transaction;  
delete from info where id=1;
commit;

此时数据库中的表数据以下:

id name 建立版本(事务ID) 删除版本(事务ID)
1 a 1 4
2 b 1 undefined
3 c 1 undefined
4 d 3 undefined

接着执行事务 ID 为 2 的 事务(2),根据 SELECT 检索条件能够知道,它会检索建立时间(建立事务的 ID )小于当前事务 ID 的行和删除时间(删除事务的 ID )大于当前事务的行,而 id=4 的行上面已经说过,而 id=1 的行因为删除时间(删除事务的 ID )大于当前事务的 ID ,因此 事务2 的 (2) select * from info 也会把 id=1 的数据检索出来。因此,事务2 中的两条 select 语句检索出来的数据都以下:

id name 建立版本(事务ID) 删除版本(事务ID)
1 a 1 4
2 b 1 undefined
3 c 1 undefined

UPDATE

InnoDB 执行 UPDATE,其实是新插入了一行记录,并保存其建立时间为当前事务的 ID ,同时保存当前事务 ID 到要 UPDATE 的行的删除时间。

  • 假设3
    假设在执行完 事务2 的 (1) 后又执行,其它用户执行了事务 3和 4,这时,又有一个用户对这张表执行了 UPDATE 操做:

第五个事务:

start  transaction;
update info set name='b' where id=2;
commit;

根据update的更新原则:会生成新的一行,并在原来要修改的列的删除时间列上添加本事务ID,获得表以下:

id name 建立版本(事务ID) 删除版本(事务ID)
1 a 1 4
2 b 1 5
3 c 1 undefined
4 d 3 undefined
2 b 5 undefined

继续执行 事务2 的 (2) ,根据 select 语句的检索条件,获得下表:

id name 建立版本(事务ID) 删除版本(事务ID)
1 a 1 4
2 b 1 5
3 c 1 undefined

仍是和 事务2 中 (1) select 获得相同的结果。

❀ 总结:

  • SELECT
    读取建立版本号小于或等于当前事务版本号,而且删除版本号为空或大于当前事务版本号的记录。如此能够保证在事务在读取以前记录是存在的。
  • INSERT
    将当前事务的版本号保存至插入行的建立版本号。
  • UPDATE
    新插入一行,并以当前事务的版本号做为新行的建立版本号,同时将原记录行的删除版本号设置为当前事务版本号。
  • DELETE
    将当前事务的版本号保存至行的删除版本号。

例子参考:https://blog.csdn.net/whoamiy...


四、 InnoDB 如何解决幻读问题

在 InnoDB 中分为快照读当前读。快照读读的是数据的快照,也就是数据的历史版本;当前读就是读的最新版本的数据,而且在读的时候加锁,其余事务都不能对当前行作修改。

  • 快照读:简单的 select 操做,属于快照读,不加锁。
    select * from table where ?;
  • 当前读:特殊的读操做,插入、更新、删除操做,属于当前读,须要加锁。
    select * from table where ? lock in share mode;
    select * from table where ? for update;
    insert into table values (…);
    update table set ? where ?;
    delete from table where ?;

对于上面当前读的语句,第一条读取记录加共享锁,其余的所有加排它锁。

也就是说在作数据的修改操做时,都会使用当前读的方式,当前读是经过行锁和间隙锁控制的,此时是加了排他锁的,全部其余的事务都不能动当前的事务,因此避免了出现幻读的可能。

而为了防止幻读,行锁和间隙锁扮演了重要角色,下面简单说一下:

  • 行锁
    字面意思简单理解对数据行加锁,注意 InnoDB 行锁是经过给索引上的索引项加锁来实现的,也就是说只有经过索引条件检索数据,InnoDB才使用行级锁,不然,InnoDB将使用表锁!
  • 间隙锁
    间隙锁就是用来为数据行之间的间隙来进行加锁。

举个例子:

select * from info where id > 5;

上面 SQL 中,其中 id 是主键,假设在一个 事务 A 中执行这个查询,第一次查询为一个 结果集 1 。在作第二次查询时,另外一个 事务 B 在 info 表进行了插入数据 7 和 10 的操做。在 事务 A 再次执行此查询查询出 结果集 2 的时候,发现多了几条记录,如此便产生了幻读。

  • 结果集1
6,8,9
  • 结果集2
6,7,8,9,10

因此试想为了防止幻读,咱们不但要现存的 id > 5 的数据行(6,8,9)上面加锁(行锁),还要在它们的间隙加锁(间隙锁)。

咱们以区间来表示要加锁对象:

(5,6]
(6,8]
(8,9]
(9,+∞)

其中区间的右闭即为要加的行锁,而区间的范围便是要加的间隙锁。

5、结语

关于脏读、不可重复读和幻读的理解便记录到这里了,因笔者水平有限,若有错误欢迎指正。

欢迎访问 我的博客 获取更多知识分享。