一、前言

本文主要对4种事务隔离级别，具体举例说明各自可能会存在的3种读现象的问题。

1.1、4种事务隔离级别

什么是隔离？
因为AB两事务存在时空冲突性，即执行时间和操作记录上都存在交集，否则就可以认为是不相关的，没有必要隔离。
那么4种事务隔离级别各自是什么，下面列出：

这里对脏读、不可重复读和幻读问题，各自举例描述。

脏读，Dirty Read，事务A读到了无效的脏数据。
不可重复读，Non-repeatable Read，事务A第一次读到了存在的某条记录，后面又读该记录（被事务B对刚刚存在的该记录update或delete），两次结果不一致。
幻读，Phantom Read，事务A第一次读到了某些结果集的数据，后面再次读，却读到了第一次中不存在的数据（被事务B在符合A第一次查询where条件的结果集中，insert了新的记录），两次结果不一致。

不可重复读和幻读，一般都是一个事务受到其他事务的影响，导致自身事务前后两次读结果不一致。
但是区别在于，不可重复读强调对先前存在的记录进行操作（对已存在的记录操作只能是update或delete），而幻读则强调对先前不存在的记录进行操作（对不存在的记录操作也只能是insert）。

在这里逐个举例说明各个事务隔离级别可能存在的读问题。
查看Spring中@Transactional属性Isolation的注释也可以发现，读未提交存在脏读、不可重复读、幻读，读已提交存在不可重复读、幻读，可重复读存在幻读，串行化防止脏读、不可重复读、幻读。

ps，点击这篇数据库事务隔离级别举例详解（续）可以通过操作层面看到这些读问题。

下面的举例假设事务A、B一起执行。

脏读：
时刻1，事务B修改Jay的工资由1爽（爽：货币计量单位，等于1.6亿元人民币）变为2爽，但还没提交；
时刻2，事务A是可以读到Jay的工资变成2爽；
时刻3，事务B试图提交但失败，导致回滚为1爽，那事务A读到的2爽就是脏数据，这就是一次脏读。
不可重复读（update的影响）：
时刻1，事务A读到了Jay的工资是1爽；
时刻2，事务B更改了Jay的工资为2爽，但还没提交；
时刻3，事务A再读，这次读到2爽没问题，那事务A先后读到了同一记录的2种数据版本，这就是一次update导致的不可重复读。
不可重复读（delete的影响）：
时刻1，事务A读到了Jay的工资是1爽；
时刻2，事务B删除Jay的工资记录，但还没提交；
时刻3，事务A再读，这次读不到Jay的工资记录，那也等同于事务A先后读到了同一记录的2种数据版本，这是一次delete导致的不可重复读。
幻读：
时刻1，事务A读到了Jay的工资有一条记录（select salary from pay_sheet where name=‘Jay’）；
时刻2，事务B在薪资表pay_sheet中为Jay添加了一项额外的薪酬，但还没提交；
时刻3，事务A再查，这次查到莫名其妙多了一条记录，那事务A第二次的多读，就是一次insert导致的幻读。

不可重复读（update的影响）：
时刻1，事务A读到了Jay的工资是1爽；
时刻2，事务B更改了Jay的工资为2爽，且已提交；
时刻3，事务A再读，这次读到2爽没问题，那事务A先后读到了同一记录的2种数据版本，这就是一次update导致的不可重复读。
不可重复读（delete的影响）：
时刻1，事务A读到了Jay的工资是1爽；
时刻2，事务B删除Jay的工资记录，且已提交；
时刻3，事务A再读，这次读不到Jay的工资记录，那也等同于事务A先后读到了同一记录的2种数据版本，这是一次delete导致的不可重复读。
幻读：
时刻1，事务A读到了Jay的工资有一条记录（select salary from pay_sheet where name=‘Jay’）；
时刻2，事务B在薪资表pay_sheet中为Jay添加了一项额外的薪酬，且已提交；
时刻3，事务A再查，这次查到莫名其妙多了一条记录，那事务A第二次的多读，就是一次insert导致的幻读。

幻读：
时刻1，事务A读到了Jay的工资有一条记录（select salary from pay_sheet where name=‘Jay’）；
⚠️注意：这时候可重复读会将读到的这些记录行加锁，事务B没法去修改删除，但对事务B进行insert就没办法了，锁起不了作用。
时刻2，事务B在薪资表pay_sheet中为Jay添加了一项额外的薪酬，且已提交；
时刻3，事务A再查，这次查到莫名其妙多了一条记录，那事务A第二次的多读，就是一次insert导致的幻读。

串行化通过读写锁，读写写读写写互斥，读读不互斥的锁机制，牺牲数据库的并发性能，避免了脏读、不可重复读和幻读的问题。