首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >mysql事务隔离级别/脏读/不可重复读/幻读详解

mysql事务隔离级别/脏读/不可重复读/幻读详解

作者头像
菩提树下的杨过
发布2020-04-08 17:50:12
1K0
发布2020-04-08 17:50:12
举报

一、四种事务隔离级别

1.1 read uncommitted 读未提交

即:事务A可以读取到事务B已修改但未提交的数据。

除非是文章阅读量,每次+1这种无关痛痒的场景,一般业务系统没有人会使用该事务隔离级别,标准实在太宽松了。

1.2 read committed 读已提交(简称RC)

即:事务A只能读取到事务B修改并已提交的数据。

这个级别相对要严格一些,至少是要等其它事务把变更提交到db,才能读取到,听上去蛮靠谱的。但是有些业务场景,比如会员系统中,如果要在一个事务中,多次读取用户身份,判断是否会员,如果刚开始读取到该用户是会员,做了一些逻辑处理,后面又读到用户不是会员了,这就有点崩溃,不知道如何继续。这种希望同1个事务中,关键数据不管读取多次次,结果都一样,RC级别就不行了。

1.3 repeatable read 可重复读

即:同一个事务中,多次读取某一行记录,始终是一样的值,不管在此期间,其它事务有没有修改过该数据(不论是否提交)。该级别解决了RC不可重复读的问题,但是存在幻读问题(幻读后面会详解)。

1.4 serializable 串行化

即:一个事务在修改其它数据时,如果有其它事务也想改,必须等前面的事务提交或回滚后,才能继续。最严格的级别,但是性能最低,也几乎没人用。

二、脏读/不可重复读/幻读 2.1 脏读

验证:

a. 找一个mysql环境,建一个测试表t_people,就2列 id ,name

b. 开二个mysql终端,连到db上,为方便讲解,这2个终端称为“终端1”、“终端2”,终端1里输入:

set session transaction isolation level read uncommitted;
start transaction;

即:设置当前会话的隔离级别为"读未提交"。

终端2里,输入:

start transaction;
update t_people set name='xxx' where id=1;

然后再回到“终端1”,执行

select id,name from t_people where id=1;

可以看到,读取到了未提交的脏数据 。 终端2里,此时如果执行rollback回滚

终端1里,继续执行

select id,name from t_people where id=1;

可以发现最新结果,已经是回滚后的数据。很显然:如果有脏读问题出现,就更加保证不了“可重复读”。

2.2 不可重复读

将事务隔离级别设置成read committed(即:读已提交),可解决脏读问题,但满足不了“可重复读需求”。

验证方法跟刚才类似,终端1里输入:

set session transaction isolation level read committed;

将级别设置成RC,然后2个终端里都开启事务,终端2中,修改一行数据,但是不提交,此时终端1里应该是读不到终端2修改的数据。然后终端2提交,终端1才能读到修改后的数据。终端2如果继续修改、提交,终端1里再读取这1行,将是最新的值。(也就是只说,只要终端2不断修改,不断提交,终端1里就能读到这行不同的新值,即:保证不了同1个事务中,同一行数据,多次重复读取的值不变)

2.3 幻读

将隔离级别继续调整至Repeatable Read,还是刚才的场景,变成这样:

事务A对于同一行数据,不管读多少次,始终是相同的值,完全不理会有没有其它事务在修改它。有点:“两耳不闻窗外事,一心只读圣贤书”的味道。但是这也有问题,比如秒杀订单系统中,事务A第1次读取商品库存,发现还有1个,可以下单,赶紧继续,但是此时,可能有另一个事务,也在下单,已经提交了订单,把库存减为0了,事务A并不知道,因为多次读取库存的值是一样的,还是1,最后仍然把订单创建了,形成超卖。

验证方法:

set session transaction isolation level repeatable read;

剩下的步骤跟前面类似,就不重复赘述了。 

2.4 串行化

从db层面,要想同时解决脏读、不可重复读、幻读,只有串行化这个级别可以做到。

set session transaction isolation level serializable;

如下图:终端1设置串行化后,紧接着select xxx where id=1这条语句后,id=1的这行记录,就被锁了。

在终端2里,更新其它记录(即:id不等于1)可以正常成功,但是更新id=1 时,就会卡住,除非终端1把事务提交或回滚,否则将一直卡着,直到超时失败。

小结:

隔离级别

存在的问题

读未提交

脏读、不可重复读、幻读

读已提交

不可重复读、幻读

可重复读

幻读

串行化

性能问题

隔离级别越严格,db综合性能越低。

建议:

大多数情况下,RC(读已提交)基本上就足够了,如果并发度高,可以考虑“RC级别+(应用层)分布式锁”,这样即能保证数据正确,对db的性能压力也较低。

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2020-04-06 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
云数据库 SQL Server
腾讯云数据库 SQL Server (TencentDB for SQL Server)是业界最常用的商用数据库之一,对基于 Windows 架构的应用程序具有完美的支持。TencentDB for SQL Server 拥有微软正版授权,可持续为用户提供最新的功能,避免未授权使用软件的风险。具有即开即用、稳定可靠、安全运行、弹性扩缩等特点。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档