一、四种事务隔离级别
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的性能压力也较低。