MySQL的四种事务隔离级别-案例分析

本文采用的开发环境以及软件如下：
win10，mysql5.7.29，innodb，Toad for MySQL 8.0 Freeware

一、基本概念

脏读：事务A和事务B同时打开，对于同一条数据，事务B执行了更新操作（没有提交），事务A能查询到事务B刚更新的数据，此时事务B回退，则事务A查到的就是脏数据。
不可重复读：在事务A多次读取过程中（同一条查询语句），事务B更新数据并提交，导致事务A多次读取到的数据不一致。
幻读：假设此时事务A先查询到4条数据，然后进行更新，在事务A更新前，事务B先插入一条数据并提交，事务A更新后重新查一遍，发现有五条满足条件数据，但是只有4条更新了，就像发生了幻象一样，就是幻读。

小结：对于脏读和不可重复读，主要看是否提交（commit），同一条数据提交前能查到就是脏读，提交后能查到就是不可重复读，比较容易区分。比较难区分的是不可重复读和幻读，不可重复读侧重于数据的修改，幻读侧重于数据的新增与删除。

二、下面分情况进行讨论

首先要把自动提交关闭

2、1 read uncommitted，产生脏读问题

设置数据隔离级别为：read uncommitted
事务A首先查到b=5的数据，

事务B执行更新语句，将b=5的数据，a更新为10，但是不执行提交（commit）;


此时事务A执行查询，发现能查到事务B未提交的数据，这就是脏读
说明：read uncommitted级别会造成脏读。

2、2 read committed，产生不可重复读问题

首先把事务B回退掉，让数据保持（6,5）。
设置数据隔离级别为：read committed
事务A首先查到b=5的数据，


事务B执行更新语句，将b=5的数据，a更新为10，但是不执行提交（commit）;

此时事务A执行查询，发现查不到事务B更新的数据。

事务B执行提交操作（commit），事务A再进行查询则可以查到最新数据。
说明：read committed级别解决了脏读

虽然read committed解决了脏读，但是还没有解决不可重复读，请往下看。
事务B将b=5更新a=15，并执行commit

此时事务A再次进行查询，发现读到了事务B刚刚更新的数据，事务A同一条SQL执行两次，但是两次查询到的结果却不一样，出现不可重复读的问题。

2、3 REPEATABLE read，解决不可重复读和幻读问题

设置数据隔离级别为：REPEATABLE read

事务A执行查询，此时数据是（15,5）

事务B执行更新语句，将b=5更新a=16，并执行提交（commit）操作。

此时事务A执行查询，发现还是（15,5）并没有读取到事务B提交的数据，事务A前后两次读取的数据一样。
说明：REPEATABLE read级别解决了不可重复读问题

MySQL与标准SQL不同的是，在标准SQL中REPEATABLE read级别会造成幻读问题，但是mysql的innodb引擎在REPEATABLE read级别下，采用MVCC（多版本并发控制）解决了幻读问题。

下面进行范围查询测试
事务A首先查询 a>=7的，查出来三条数据。

事务B插入一条（17,18）的数据，并提交

此时事务A再次进行查询，发现还是三条

如果此时事务A执行一条update，再进行查询，则会查询到四条数据

由此可见，innodb解决了可重复读和幻读问题，因为innodb的多版本并发控制，在REPEATABLE read级别下，读取的都是事务开启时的快照数据，所以保证了可重复读，并解决了幻读问题。select操作不会更新版本号，是快照读（历史版本）；insert、update和delete会更新版本号，是当前读（当前版本）。

2、4 SERIALIZABLE，解决幻读问题

设置数据隔离级别为：SERIALIZABLE

事务A执行查询

事务B执行插入操作，发现插入失败，因为SERIALIZABLE会锁表，因此不会出现幻读的情况，这种隔离级别是最安全的，但是并发性极低，基本上不会用到。

总结：
1、MySQL数据库默认隔离级别是REPEATABLE read。
2、因为REPEATABLE read（可重复读）的隔离级别下使用了MVCC机制（多版本并发控制），总是读取事务开始时的行数据，所以能都保证每次读取的数据都一致，解决了不可重复读和幻读的问题。
3、SERIALIZABLE会进行锁表，所以能解决幻读问题