事务隔离级别

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了事务隔离级别相关的知识,希望对你有一定的参考价值。

SQL标准中定义了四种隔离级别,每种隔离级别都规定了一个事务中所做的修改,哪些事务内和事务间是可见的,哪些是不可见的。较低级别的隔离通常可以执行更高的并发,系统的开销也更低。

***每种存储引擎实现的隔离级别不尽相同,后面会简单举例介绍***

注意:我们讨论隔离级别的场景,主要是在多个事务并发的情况下,因此,接下来的讲解都围绕事务并发。(并发的概念自己去查)

脏读:

是两个事务在一个连接里才行:即同连接中事务T1修改数据,事务T2读取数据;mysql各个进程之间在不提交的情况下是不会出现脏读的。一个事务读到另外一个

事务还没有提交的数据叫做脏读,不意味着在数据库里一个事务一定会读到另外一个事务还没有提交的数据(有点绕)。



不可重复读:

启动A事务——>A查询表——>启动B事务——>B查询表——>B修改表——B事务提交(不会出错哦,郁闷中。。。)——>A查询表(数据会保证和上一次A查询的数据一致)——>A事务修改表(不出错)——>A事务提交(事务提交成功,不出错)

这样势必造成一个结果就是B修改的数据对于A是透明的,就好像不存在,而且最终会覆盖B的结果


幻读:

解决了不重复读,保证了同一个事务里,查询的结果都是事务开始时的状态(一致性)。但是,如果另一个事务同时提交了新数据,本事务再更新时,就会“惊奇的”发现了这些新数据,貌似之前读到的数据是“鬼影”一样的幻觉。



隔离级别的类型如下:

技术分享

2.2.1 READ UNCOMMITED(未提交读)

1)在READ UNCOMMITED级别,事务中的修改,即使没有提交,对其他事务也都是可见的。

2)事务是可以读取未提交的数据,这也被称为脏读(Dirty Read。允许脏读,但不允许更新丢失。

3)这个级别会导致很多的问题:脏读、幻读、不可重复读等。

案例分析:

   公司发工资了,领导把5000元打到隔壁老王的账号上,但是该事务并未提交,而隔壁老王正好去查看账户,发现工资已经到账,是5000元整,非常高兴。可是不幸的是,领导发现发给隔壁老王的工资金额不对,是2000元,于是迅速回滚了事务,修改金额后,将事务提交,最后隔壁老王实际的工资只有2000元,隔壁老王空欢喜一场!!!

技术分享

出现上述情况,即我们所说的脏读,两个并发的事务,事务A:给隔壁老王发工资事务B:隔壁老王查询工资账户,事务B读取了事务A尚未提交的数据。

   从性能上来说,READ UNCOMMIT不会比其他的级别好太多,但却缺乏其他级别很多好处,除非真的有必要的理由,在实际应用中一般很少使用。

当隔离级别设置为Read uncommitted时,就可能出现脏读,如何避免脏读,请看下一个隔离级别

2.2.2 READ COMMIT(提交读)

简单定义:一个事务开始时,只能“看见”已经提交的事务所做的修改。【一个事务从开始直到提交之前,所做的任何修改对其他事务所都是不可见的】

1)大多数数据库系统默认的隔离级别都是READ COMMIT(如:SQL ServerOracle),但是MySQL不是。

2)这个级别有时候也叫做不可重复读(norepeatable read),因为两次执行同样的查询,可能会导致不一样的结果。

这里举例说明:

隔壁老王拿着工资卡去消费,系统读取到卡里确实有2000元,而此时她的老婆也正好在网上转账,把隔壁老王工资卡的2000元转到另一账户,并在隔壁老王之前提交了事务,当隔壁老王扣款时,系统检查到隔壁老王的工资卡已经没有钱,扣款失败,隔壁老王十分纳闷,明明卡里有钱,为何......

技术分享

出现上述情况,即我们所说的不可重复读,两个并发的事务,事务A隔壁老王消费事务B隔壁老王的老婆网上转账,事务A事先读取了数据,事务B紧接了更新了数据,并提交了事务,而事务A再次读取该数据时,数据已经发生了改变。

当隔离级别设置为Read committed时,避免了脏读,但是可能会造成不可重复读。解决此问题,请看下一个级别。

2.2.3 REPEATABLE READ(可重复读)

(1) 解决了脏读问题,保证了在同一个事物中多次读取同样的记录的结果是一致的。

(2) MySQL默认的事务隔离级别。

3)【理论上】还是无法解决幻读的问题。

---幻读(Phantom Read):指的是当某个事务还在读取某个范围内的记录时,另外一个事务又在该范围内插入了新的记录,当之前的事务再次读取该范围的记录时,会产生幻行(Phantom Row)。

InnoDBXtraDB存储引擎通过多版本并发控制(MVCC,Multiversion Concurrency Control)解决了幻读的问题

案例分析:

隔壁老王的老婆工作在银行部门,她时常通过银行内部系统查看隔壁老王的信用卡消费记录。有一天,她正在查询到隔壁老王当月信用卡的总消费金额(select sum(amount) from transaction where month = 本月)为80元,而隔壁老王此时正好在外面胡吃海塞后在收银台买单,消费1000元,即新增了一条1000元的消费记录(insert transaction ... ),并提交了事务,随后隔壁老王的老婆将隔壁老王当月信用卡消费的明细打印到A4纸上,却发现消费总额为1080元,隔壁老王的老婆很诧异,以为出现了幻觉,幻读就这样产生了。

技术分享

上面的情况,即为出现的幻读情况。此级别解决了脏读问题,解决解决幻读问题,请看下面的级别。

2.2.4 SERIALIZABLE(可串行化)

可串行化:在读取的每一行数据上加锁,保持序列化

(1) 最高的隔离级别。

(2) 通过强制事务串行执行,避免了前面说的幻读问题。

(3) 代价也花费最高,性能很低,加锁耗时、锁争问题。

(4) 一般很少使用,在该级别下,事务顺序执行,不仅可以避免脏读、不可重复读,还避免了幻像读。

(5) 只有在非常需要确保数据的一致性而且可以接受没有并发的情况,才考虑采用该级别。

技术分享

事务的隔离级别:

READ UNCOMMIT:脏读,不可重复度,幻读

READ COMMIT:不可重复度,幻读

REPEATABLE READ:幻读  (InnoDB和XtraDB存储引擎通过多版本并发控制(mvcc,Multiversion Concurrency Control)解决幻读问题)

SERIALIZABLE:加锁读



本文出自 “晴空” 博客,谢绝转载!

以上是关于事务隔离级别的主要内容,如果未能解决你的问题,请参考以下文章

Spring事务隔离级别:REQUIRES_NEW使用细节

MySQL的默认事务隔离级别是?

如何更改mysql事务隔离级别

mysql 的事务隔离级别 及各个隔离级别应用场景,详细

MySQL-8事务与隔离级别IO

数据库事务隔离级别 一般用哪个