一、四种事务隔离级别

1.1read 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的性能压力也较低。