百度360必应搜狗淘宝本站头条
当前位置:网站首页 > 技术教程 > 正文

MySQL/InnoDB中的事务隔离级别(mysql数据库事务隔离级别默认)

mhr18 2024-10-09 12:22 27 浏览 0 评论

SQL标准中的事务四种隔离级别

  • 未提交读(Read Uncommitted):允许脏读,也就是可能读取到其他会话中未提交事务修改的数据
  • 提交读(Read Committed):只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别 (不重复读)
  • 可重复读(Repeated Read):可重复读。在同一个事务内的查询都是事务开始时刻一致的,InnoDB默认级别。在SQL标准中,该隔离级别消除了不可重复读,但是还存在幻象读
  • 串行读(Serializable):完全串行化的读,每次读都需要获得表级共享锁,读写相互都会阻塞

未提交读(Read uncommitted)

数据库一般都不会用,而且任何操作都不会加锁

mysql> select * from tx_test;
+----+-------+
| id | value |
+----+-------+
| 1 | a |
+----+-------+
1 row in set (0.00 sec)

由于MySQL的InnoDB默认是使用的RR级别,所以我们先要将该session开启成RU级别

SET session transaction isolation level read uncommitted;
_____________________________________________________________________
事务A 事务B
_____________________________________________________________________
begin; 
 begin;
_____________________________________________________________________
 select * from tx_test; 
 ______________
 id value 
 ______________
 1 a 
 ______________
___________________________________________________________________
insert into tx_test(value) values('b');
____________________________________________________________________
 select * from tx_test; 
 ______________
 id value 
 ______________
 1 a 
 ______________
 2 b
 ______________
 读到事务A还未commit的行,出现脏读
_____________________________________________________________________
 commit;
commit;
_____________________________________________________________________

已提交读(Read committed)

在RC级别中,数据的读取都是不加锁的,但是数据的写入、修改和删除是需要加锁的。

SET session transaction isolation level read committed;
SET SESSION binlog_format = 'ROW';(或者是MIXED)
_____________________________________________________________________
事务A 事务B
_____________________________________________________________________
begin; begin;
_____________________________________________________________________
 
update tx_test set value='aa' where id=1; update tx_test set value='aaa' where id=1;
___________________________________________________________________________________________
 ERROR 1205 (HY000): Lock wait timeout exceeded; 
 try restarting transaction
_____________________________________________________________________
 
commit;
_____________________________________________________________________

为了防止并发过程中的修改冲突,事务A中MySQL给id=1的数据行加锁,并一直不commit(释放锁),那么事务B也就一直拿不到该行锁,wait直到超时。

可重复读(Repeatable read)

这是MySQL中InnoDB默认的隔离级别。我们姑且分“读”和“写”两个模块来讲解。

读就是可重读,可重读这个概念是一事务的多个实例在并发读取数据时,会看到同样的数据行。

RC模式下的展现(不可重读)

__________________________________________________________________________________________
事务A 事务B
__________________________________________________________________________________________
begin; 
 begin;
__________________________________________________________________________________________
 
select * from tx_test; 
______________ 
 id value 
______________
 1 aa 
______________
 2 b
______________
__________________________________________________________________________________________
 update tx_test set value='bb' where id=2;
__________________________________________________________________________________________
 
 commit;
__________________________________________________________________________________________
select * from tx_test; 
______________
 id value 
______________
 1 aa 
______________
 2 bb
______________
读到了事务B修改的数据,和第一次查询的结果不一样,
是不可重读的。
_________________________________________________________________________________________
commit
_________________________________________________________________________________________

事务B修改id=2的数据提交之后,事务A同样的查询,后一次和前一次的结果不一样,这就是不可重读(重新读取产生的结果不一样)。这就很可能带来一些问题,那么我们来看看在RR级别中MySQL的表现:

事务A 事务B 事务C
_________________________________________________________________________________________________________________________________________
begin; 
 begin; begin;
_________________________________________________________________________________________________________________________________________
 
select * from tx_test; 
______________
 id value 
______________
 1 aa 
______________
 2 bb
______________
___________________________________________________________________________________________________________________________________________
 update tx_test set value='aaa' where id=1; insert into tx_test(value) values('c');
___________________________________________________________________________________________________________________________________________
 
 commit; commit;
____________________________________________________________________________________________________________________________________________
select * from tx_test; 
______________
 id value 
______________
 1 aa 
______________
 2 bb
______________
没有读到事务B修改的数据,和第一次sql读取的一样,是可重复读的。
没有读到事务C新添加的数据。
_________________________________________________________________________________________
commit
_________________________________________________________________________________________

我们注意到,事务A先做了一次读取,事务B中间修改了id=1的数据,并commit之后,事务A第二次读到的数据和第一次完全相同。所以说它是可重读的。

不可重复读和幻读的区别

不可重复读重点在于update和delete,而幻读的重点在于insert。

如果使用锁机制来实现这两种隔离级别,在可重复读中,该sql第一次读取到数据后,就将这些数据加锁,其它事务无法修改这些数据,就可以实现可重复读了。但这种方法却无法锁住insert的数据,所以当事务A先前读取了数据,或者修改了全部数据,事务B还是可以insert数据提交,这时事务A就会发现莫名其妙多了一条之前没有的数据,这就是幻读,不能通过行锁来避免。需要Serializable隔离级别 ,读用读锁,写用写锁,读锁和写锁互斥,这么做可以有效的避免幻读、不可重复读、脏读等问题,但会极大的降低数据库的并发能力。

所以说不可重复读和幻读最大的区别,就在于如何通过锁机制来解决他们产生的问题。

上文说的,是使用悲观锁机制来处理这两种问题,但是MySQL、ORACLE、PostgreSQL等成熟的数据库,出于性能考虑,都是使用了以乐观锁为理论基础的MVCC(多版本并发控制)来避免这两种问题。

可串行化(Serializable )

读加共享锁,写加排他锁,读写互斥。使用的悲观锁的理论,实现简单,数据更加安全,但是并发能力非常差。如果你的业务并发的特别少或者没有并发,同时又要求数据及时可靠的话,可以使用这种模式。

相关推荐

Redis合集-使用benchmark性能测试

采用开源Redis的redis-benchmark工具进行压测,它是Redis官方的性能测试工具,可以有效地测试Redis服务的性能。本次测试使用Redis官方最新的代码进行编译,详情请参见Redis...

Java简历总被已读不回?面试挂到怀疑人生?这几点你可能真没做好

最近看了几十份简历,发现大部分人不是技术差,而是不会“卖自己”——一、简历死穴:你写的不是经验,是岗位说明书!反面教材:ד使用SpringBoot开发项目”ד负责用户模块功能实现”救命写法:...

redission YYDS(redission官网)

每天分享一个架构知识Redission是一个基于Redis的分布式Java锁框架,它提供了各种锁实现,包括可重入锁、公平锁、读写锁等。使用Redission可以方便地实现分布式锁。red...

从数据库行锁到分布式事务:电商库存防超卖的九重劫难与破局之道

2023年6月18日我们维护的电商平台在零点刚过3秒就遭遇了严重事故。监控大屏显示某爆款手机SKU_IPHONE13_PRO_MAX在库存仅剩500台时,订单系统却产生了1200笔有效订单。事故复盘发...

SpringBoot系列——实战11:接口幂等性的形而上思...

欢迎关注、点赞、收藏。幂等性不仅是一种技术需求,更是数字文明对确定性追求的体现。在充满不确定性的网络世界中,它为我们建立起可依赖的存在秩序,这或许正是技术哲学最深刻的价值所在。幂等性的本质困境在支付系...

如何优化系统架构设计缓解流量压力提升并发性能?Java实战分享

如何优化系统架构设计缓解流量压力提升并发性能?Java实战分享在高流量场景下。首先,我需要回忆一下常见的优化策略,比如负载均衡、缓存、数据库优化、微服务拆分这些。不过,可能还需要考虑用户的具体情况,比...

Java面试题: 项目开发中的有哪些成长?该如何回答

在Java面试中,当被问到“项目中的成长点”时,面试官不仅想了解你的技术能力,更希望看到你的问题解决能力、学习迭代意识以及对项目的深度思考。以下是回答的策略和示例,帮助你清晰、有说服力地展示成长点:一...

互联网大厂后端必看!Spring Boot 如何实现高并发抢券逻辑?

你有没有遇到过这样的情况?在电商大促时,系统上线了抢券活动,结果活动刚一开始,服务器就不堪重负,出现超卖、系统崩溃等问题。又或者用户疯狂点击抢券按钮,最后却被告知无券可抢,体验极差。作为互联网大厂的后...

每日一题 |10W QPS高并发限流方案设计(含真实代码)

面试场景还原面试官:“如果系统要承载10WQPS的高并发流量,你会如何设计限流方案?”你:“(稳住,我要从限流算法到分布式架构全盘分析)…”一、为什么需要限流?核心矛盾:系统资源(CPU/内存/数据...

Java面试题:服务雪崩如何解决?90%人栽了

服务雪崩是指微服务架构中,由于某个服务出现故障,导致故障在服务之间不断传递和扩散,最终造成整个系统崩溃的现象。以下是一些解决服务雪崩问题的常见方法:限流限制请求速率:通过限流算法(如令牌桶算法、漏桶算...

面试题官:高并发经验有吗,并发量多少,如何回复?

一、有实际高并发经验(建议结构)直接量化"在XX项目中,系统日活用户约XX万,核心接口峰值QPS达到XX,TPS处理能力为XX/秒。通过压力测试验证过XX并发线程下的稳定性。"技术方案...

瞬时流量高并发“保命指南”:这样做系统稳如泰山,老板跪求加薪

“系统崩了,用户骂了,年终奖飞了!”——这是多少程序员在瞬时大流量下的真实噩梦?双11秒杀、春运抢票、直播带货……每秒百万请求的冲击,你的代码扛得住吗?2025年了,为什么你的系统一遇高并发就“躺平”...

其实很多Java工程师不是能力不够,是没找到展示自己的正确姿势。

其实很多Java工程师不是能力不够,是没找到展示自己的正确姿势。比如上周有个小伙伴找我,五年经验但简历全是'参与系统设计''优化接口性能'这种空话。我就问他:你做的秒杀...

PHP技能评测(php等级考试)

公司出了一些自我评测的PHP题目,现将题目和答案记录于此,以方便记忆。1.魔术函数有哪些,分别在什么时候调用?__construct(),类的构造函数__destruct(),类的析构函数__cal...

你的简历在HR眼里是青铜还是王者?

你的简历在HR眼里是青铜还是王者?兄弟,简历投了100份没反应?面试总在第三轮被刷?别急着怀疑人生,你可能只是踩了这些"隐形求职雷"。帮3630+程序员改简历+面试指导和处理空窗期时间...

取消回复欢迎 发表评论: