数据库之事务隔离级别

标签: mysql  事务隔离级别

在了解隔离级别之前,我们先了解几个名词:

1、脏读

所谓脏读,就是指事务A读到了事务B还没有提交的数据,比如银行取钱,事务A开启事务,此时切换到事务B,事务B开启事务-->取走100元,此时切换回事务A,事务A读取的肯定是数据库里面的原始数据,因为事务B取走了100块钱,并没有提交,数据库里面的账务余额肯定还是原始余额,这就是脏读。

2、不可重复读

所谓不可重复读,就是指在一个事务里面读取了两次某个数据,读出来的数据不一致。还是以银行取钱为例,事务A开启事务-->查出银行卡余额为1000元,此时切换到事务B事务B开启事务-->事务B取走100元-->提交,数据库里面余额变为900元,此时切换回事务A,事务A再查一次查出账户余额为900元,这样对事务A而言,在同一个事务内两次读取账户余额数据不一致,这就是不可重复读。

3、幻读

所谓幻读,就是指在一个事务里面的操作中发现了未被操作的数据。比如学生信息,事务A开启事务-->修改所有学生当天签到状况为false,此时切换到事务B,事务B开启事务-->事务B插入了一条学生数据,此时切换回事务A,事务A提交的时候发现了一条自己没有修改过的数据,这就是幻读,就好像发生了幻觉一样。幻读出现的前提是并发的事务中有事务发生了插入、删除操作。

TIP:不可重复读是能读到其它事务已经提交的数据,幻读是读不到其它事务已提交的数据?

四种隔离级别

隔离级别 脏读 不可重复读 幻读
读未提交 可能 可能 可能
读已提交 不可能 可能 可能
可重复读 不可能 不可能 可能
串行化 不可能 不可能 不可能

一. 读未提交

具体用户 A 的操作如下:

set session transaction isolation level read uncommitted;
start transaction;
select * from account; 

结果如下:

用户 B 的操作如下:

set session transaction isolation level read uncommitted;
start transaction; 
update account set account=account+200 where id = 1;

随后我们在 A 用户中查询数据,结果如下:

结论一

我们将事务隔离级别设置为 read uncommitted,即便是事务没有 commit,但是我们仍然能读到未提交的数据,这是所有隔离级别中最低的一种

那么这么做有什么问题吗?

那就是我们在一个事务中可以随随便便读取到其他事务未提交的数据,这还是比较麻烦的,我们叫脏读。我不知道这个名字是怎么起的,为了增强大家的印象,可以这么想,这个事务好轻浮啊,饥渴到连别人没提交的东西都等不及,真脏,呸!

实际上我们的数据改变了吗?

答案是否定的,因为只有事务 commit 后才会更新到数据库。

二. 读已提交--- 大多数数据库默认的隔离级别

同样的办法,我们将用户 B 所在的会话当前事务隔离级别设置为 read commited。

在用户 A 所在的会话中我们执行下面操作:

update account set account=account-200 where id=1;

我们将 id=1 的用户 account 减 200。然后查询,发现 id=1 的用户 account 变为 800。

在 B 用户所在的会话中查询:

select * from account;

结果如下:

我们会发现数据并没有变,还是 1000。

接着在会话 A 中我们将事务提交:

commit;

在会话 B 中查询结果如下:

结论二:

当我们将当前会话的隔离级别设置为 read committed 的时候,当前会话只能读取到其他事务提交的数据,未提交的数据读不到。

那么这么做有什么问题吗?

那就是我们在会话 B 同一个事务中,读取到两次不同的结果。这就造成了不可重复读,就是两次读取的结果不同。这种现象叫不可重复读。

三. 可重复读---MySQL 默认的隔离级别

现在有个需求,就是老板说在同一个事务中查询结果必须保持一致,如果你是数据库,你会怎么做?数据库是这么做的。

在会话 B 中我们当前事务隔离级别为 repeatable read。具体操作如下:

set session transaction isolation level repeatable read;
start transaction;

接着在会话 B 中查询数据:

我们在 A 用户所在会话中为表 account 添加一条数据:

insert into account(id,account) value(3,1000);
commit;

然后我们查询看数据插入是否成功:

回到 B 用户所在的会话,我们查询结果:

用户 B 在他所在的会话中想插入一条新数据 id=3,value=1000。来我们操作下:

什么?竟然插不进去,说我数据重复?

用户 B 当然不服啊,因为查询到数据只有两条啊,为什么插入 id=3 说我数据重复了呢?

我再看一遍,莫非我眼花了?

试想一下,在实际中用户 A 和用户 B 肯定是相互隔离的,彼此不知道操作什么。用户 B 碰到这种现象,肯定会炸毛的啊,明明不存在的数据,插入却说主键 id=3 数据重复了。

结论三:

当我们将当前会话的隔离级别设置为 repeatable read 的时候,当前会话可以重复读,就是每次读取的结果集都相同,而不管其他事务有没有提交。

有什么问题吗?

管他呢,老板的要求满足了。要一个事务中读取的数据一致(可重复读)。我只能这么做啊,打肿脸装胖子。数据已经发生改变,但是我还是要保持一致。但是,出现了用户 B 面对的问题,这种现象叫幻读(记得当时就在这个地方纠结好久,到底什么是幻读啊)。

四. 串行化

同样,我们将用户 B 所在的会话的事务隔离级别设置为 serializable 并开启事务。

set session transaction isolation level serializable;
start transaction;

在用户 B 所在的会话中我们执行下面操作:

select * from account;

结果如下:

那我们这个时候在用户 A 所在的会话中写数据呢?

我们发现用户 A 所在的会话陷入等待,如果超时(这个时间可以进行配置),会出现 Lock wait time out 提示:

如果在等待期间我们用户 B 所在的会话事务提交,那么用户 A 所在的事务的写操作将提示操作成功。

结论四:

当我们将当前会话的隔离级别设置为 serializable 的时候,其他会话对该表的写操作将被挂起。可以看到,这是隔离级别中最严格的,但是这样做势必对性能造成影响。所以在实际的选用上,我们要根据当前具体的情况选用合适的。

在可重复读的隔离级别下如何解决幻读

很明显可重复读的隔离级别没有办法彻底的解决幻读的问题,如果我们的项目中需要解决幻读的话也有两个办法:

  • 使用串行化读的隔离级别
  • MVCC+next-key locks:(MVCC是解决读写并行的幻读,而next key lock 是解决写写并行的幻读)

实际上很多的项目中是不会使用到上面的两种方法的,串行化读的性能太差,而且其实幻读很多时候是我们完全可以接受的。

版权声明:本文为qq_24313635原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/qq_24313635/article/details/102880688