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