【MySQL】事物隔离级别

举报
原来是咔咔 发表于 2022/03/26 23:58:00 2022/03/26
【摘要】 author:咔咔 WeChat:fangkangfk 事务隔离级别 隔离级别读数据一致性脏读不可重复读的问题幻读未提交读 Read Uncommitted最低级别,只能保证不读取物理上损坏的数据是是是已读提交 Read committed语句级否是是可重复读取 Repeatable Read事务隔离级别否否是序列化 Seri...

author:咔咔

WeChat:fangkangfk

事务隔离级别

隔离级别 读数据一致性 脏读 不可重复读的问题 幻读
未提交读 Read Uncommitted 最低级别,只能保证不读取物理上损坏的数据
已读提交 Read committed 语句级
可重复读取 Repeatable Read 事务隔离级别
序列化 Serializable 最高级别,事务级
  • 未授权读取(未提交读 Read Uncommitted):READ-UNCOMMITTED | 0:存在脏读,不可重复读,幻读的问题。如果一个事务已经开始写数据,则另外一个数据则不会允许同时进行写操作,但允许其他事务读此行数据。隔离级别可以通过“排他写锁”实现。
  • 授权读取(已读提交 Read committed):READ-COMMITTED | 1:解决脏读的问题,存在不可重复读,幻读的问题。这个可以通过“排他写锁”实现。读取数据的事务允许其他事务继续访问该行数据,但是未提交的写事务将会禁止其他事务访问该行。
  • 可重复读取(Repeatable Read):REPEATABLE-READ | 2:解决脏读,不可重复读的问题,存在幻读的问题,默认隔离级别。可通过“共享锁”,“排他锁”实现。读取数据的事务将会禁止写事务(但允许读事务),写事务则禁止任何其他事务。
  • 序列化(Serializable):SERIALIZABLE | 3:解决脏读,不可重复读,幻读,可保证事务安全,但完全串行执行,性能最低。提供严格的事务隔离。它要求事务序列化执行,事务只能一个接着一个地执行,不能并发执行。如果仅仅通过“行级锁”是无法实现事务序列化的,必须要通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。

并发下事物会出现的问题

数据更新丢失:

俩个事物同时操作一条数据,一个事物因为异常导致数据更新丢失

脏读:

脏读是指在一个事务处理过程里读取了另一个未提交的事务中的数据。

  当一个事务正在多次修改某个数据,而在这个事务中这多次的修改都还未提交,这时一个并发的事务来访问该数据,就会造成两个事务得到的数据不一致。例如:用户A向用户B转账100元,对应SQL命令如下

当只执行第一条SQL时,A通知B查看账户,B发现确实钱已到账(此时即发生了脏读),而之后无论第二条SQL是否执行,只要该事务不提交,则所有操作都将回滚,那么当B以后再次查看账户时就会发现钱其实并没有转。


  
  1. update account set money=money+100 where name=’B’; (此时A通知B)
  2. update account set money=money - 100 where name=’A’;

不可重复读

是指在对于数据库中的某个数据,一个事务范围内多次查询却返回了不同的数据值,这是由于在查询间隔,被另一个事务修改并提交了。

  例如事务T1在读取某一数据,而事务T2立马修改了这个数据并且提交事务给数据库,事务T1再次读取该数据就得到了不同的结果,发送了不可重复读。

  不可重复读和脏读的区别是,脏读是某一事务读取了另一个事务未提交的脏数据,而不可重复读则是读取了前一事务提交的数据。

  在某些情况下,不可重复读并不是问题,比如我们多次查询某个数据当然以最后查询得到的结果为主。但在另一些情况下就有可能发生问题,例如对于同一个数据A和B依次查询就可能不同,A和B就可能打起来了……

幻读

是事务非独立执行时发生的一种现象。例如事务T1对一个表中所有的行的某个数据项做了从“1”修改为“2”的操作,这时事务T2又对这个表中插入了一行数据项,而这个数据项的数值还是为“1”并且提交给数据库。而操作事务T1的用户如果再查看刚刚修改的数据,会发现还有一行没有修改,其实这行是从事务T2中添加的,就好像产生幻觉一样,这就是发生了幻读。

  幻读和不可重复读都是读取了另一条已经提交的事务(这点就脏读不同),所不同的是不可重复读查询的都是同一个数据项,而幻读针对的是一批数据整体(比如数据的个数)。

事务异常现象展示与解决

级联回滚

隔离级别:任意

在程序运行过程中实际上,我们的事务往往是会并发运行的,可能在某一段时间内运行几个事务;而其中会有一个很现象是很难解决的但是可以减少该现象的影响,就是级联回滚;

级联回滚:就是在一段时间同时有两个及以上的事务在运行,由于最先运行的事务出现了 “异常” 导致事务不得不回滚的情况

演示

session1 session2 session3
begin; begin; begin;
select * from count where prefix = 'dz10021' |
update count set count = 1 where prefix = 'dz10021'; |
| select * from count where prefix = 'dz10021'
| update count set count = 2 where prefix = 'dz10021'; select * from count where prefix = 'dz10021'
| update count set count = 3 where prefix = 'dz10021';
这里添加一条错误的信息 |
insert into count values('dz10021', 0, 2); |
这里因为异常回滚 因为session1异常回滚 因为session1异常回滚
[Err] 1062 - Duplicate entry 'dz10021' for key 'PRIMARY' [Err] 1213 - Deadlock found when trying to get lock; try restarting transaction [Err] 1213 - Deadlock found when trying to get lock; try restarting transaction

解释:如上的情况就是因为与session1发生了异常,但是因为session2与session3依赖于session1实现某一些业务,为了保证数据的一致性的话,是会对于相互依赖操作的数据进行级联的回滚这是很有必要的,但是对于程序来说体验不好,事情快要做好了,突然因为别人的一个岔子打断,会很不舒服。

解决:可以在select * from count where prefix = 'dz10021' 加上 for update

幻读

隔离级别:RR

session1 session2
start transaction start transaction
select * from count where prefix = 'dz1'
没有发现这条数据准备新增 select * from count where prefix = 'dz1'
| 这也没发现这条数据新增
这里因为其他事情耽搁了 insert into count values('dz1', 1, 1)
| commit
处理之后新增
insert into count values('dz1', 0, 1)
出现主键冲突,如果没有设置主键就是数据重复提交

文章来源: blog.csdn.net,作者:咔咔-,版权归原作者所有,如需转载,请联系作者。

原文链接:blog.csdn.net/fangkang7/article/details/97653129

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。