innodb数据库事务的隔离级别

读未提交（Read Uncommitted）

同时开启2个事务，第一个事务里做的修改，第二个事务立刻就能查询到该变化。该隔离级别可能产生的最大问题是，当第一个事务回滚时，所以第二个事务之前读取的数据变化是没有发生的。也就是我们常说的脏读。

读已提交（Read Committed）

这个隔离级别是很多其他数据库默认的隔离级别如oracle 。同时开启2个事务，第一个事务里做的修改，第二个事务无法查询到该变化，但是如果第一个事务被提交，第二个事务立刻能获取到该数据。但是由于sql的执行和数据库事务的提交是有时间间隔的，所以还是可能发生幻读的情况。第一个事务将表中所有数据的特定字段进行修改，第二个事务向表中插入1条新的记录，第二个事务提交。第一个事务提交。在这种情况下第一个事务返回执行成功，但是表中的仍然有1条记录的数据未被修改，就好像发生了幻觉一样。而且如果在第一个事务中先查询结果条数，然后在执行更新操作，而在这个2个操作之间第二个事务提交了1条记录，就会发生更新操作跟事先查询确定的结果条数不一致的情况。也想是发生了幻觉。

可重复读（Repeatable Read）

该隔离级别是mysql默认的事务隔离级别，在该隔离级别中。第一个事务能查询到的数据，是这个事务开启时数据库的一个快照状态，所以即使第二个事务已经进行了数据提交，第一个事务依然不能发现该数据。就解决一个事务中多次查询结果条数不一致的这个问题，这个问题是幻读的一个场景。而插入和删除操作mysql 使用 Next-Key Lock 来解决幻读问题。

串行化（Serializable）

在该隔离级别所有操作都是顺序执行，不存在并发问题，所以不存在 脏读和幻读。

脏读场景

我使用的工具为DataGrip每个查询窗口相当于个一个连接。设置事务的模式手动提交，事务的隔离级别为读未提交。

image.png

第一个窗口执行语句

#确认数据信息
select user_id,balance,now() as now from user where user_id =1

结果信息

1,430000,2022-05-12 03:10:56

第二个窗口执行信息，注意当前状态未提交

update user set balance = balance+100 where user_id =1

第一窗口再次执行结果变为；

1,430100,2022-05-12 03:13:20

第二个窗口回滚事务。第一个窗口再次执行结果变为

1,430000,2022-05-12 03:18:53

如果我们在实际业务中，第一个窗口在查询到430100后就进行也后续的业务处理，在第二个窗口信息回滚后，将会产生业务损失。

幻读场景

幻读中的不可重复读现象

首先我们先将事务的隔离级别改为读以提交
第一个窗口执行

select * from user

返回结果

1   430000  2022-05-07 01:02:05
2   2000    2022-05-07 01:05:03
3   2000    2022-05-07 01:06:47

第二个窗口执行

insert into user(user_id,balance) values(4,100);
commit;

重新执行第一个窗口语句

1   430000  2022-05-07 01:02:05
2   2000    2022-05-07 01:05:03
3   2000    2022-05-07 01:06:47
4   100 2022-05-12 03:28:01

在这情况下发现数据多了1条，产生了不可重复读现象，其实也可以定义为幻读的一种情况。

幻读中数据更新现象

第一个窗口执行语句

update user set create_time = '1999-01-01 00:00:00' where user_id >0

第二个窗口执行语句

insert into user(user_id,balance) values(5,100);
commit;

第一个窗口执行语句

select * from user

第一个窗口结果

1   430000  1999-01-01 00:00:00
2   2000    1999-01-01 00:00:00
3   2000    1999-01-01 00:00:00
4   100 1999-01-01 00:00:00
5   100 2022-05-12 03:33:49

我们发现第五条记录一个createtime 没有被更新的记录，这明显不是我们想要的结果，就是幻读的第二种场景。

可重复读隔离级别幻读测试

首先将数据库隔离级别改为可重复读
第一个窗口执行语句

update user set create_time = '1999-01-01 00:00:00' where user_id >0

第二个窗口执行语句

insert into user(user_id,balance) values(6,100);
commit;

在这你会发现你的语句无法提交成功；

image.png

因为innodb 的可重复读，读操作不加锁，但是写操作是会进行锁操作的你的执行结果 最终会得到 Lock wait timeout exceeded; try restarting transaction
所以innodb 可重复读 通过 next key lock 来避免了这种幻读场景。

但是了解了mysql innodb 避免幻读的实现方式后，我们在实际的过程中也是会发生意料之外的事，因为他是通过写操作来加锁的，我们进行下面的实验；
第一个窗口执行语句

select * from user

执行结果

1   430000  1999-01-01 00:00:00
2   2000    1999-01-01 00:00:00
3   2000    1999-01-01 00:00:00
4   100 1999-01-01 00:00:00
5   100 1999-01-01 00:00:00

第二个窗口执行语句

insert into user(user_id,balance) values(6,100);
commit;

第一个窗口执行语句

select * from user

第一个窗口执行结果

1   430000  1999-01-01 00:00:00
2   2000    1999-01-01 00:00:00
3   2000    1999-01-01 00:00:00
4   100 1999-01-01 00:00:00
5   100 1999-01-01 00:00:00

第一个窗口执行语句

update user set create_time = '1999-01-01 00:00:00' where user_id >0

第一个窗口执行语句

select * from user

第一个窗口执行结果

1   430000  1999-01-01 00:00:00
2   2000    1999-01-01 00:00:00
3   2000    1999-01-01 00:00:00
4   100 1999-01-01 00:00:00
5   100 1999-01-01 00:00:00
6   100 1999-01-01 00:00:00

我们发现记录6 ，并且该记录的创建时间已经被更新为1999-01-01 00:00:00 这跟我们想想中的可重复读和幻读的解决发生了冲突。究其原因是因为我们第二个事务提交了。而且在第二个事务提交之前 我们第一个事务并没有进行写操作，所以第一个事务对于该表自然也就没有锁。就会产生这种诡异的幻读现象。那为什么6这个记录为什么会被查出来呢？因为innodb 的重复读使用的mvvc 多版本并发控制 ，这个6 是被这个事务更新的，所以他的版本号就是这个事务的版本号，所有就能看到这条记录，所以并不是破坏了可重复读，只是可重复读的实现方式导致了这个结果。

ps:如果你在开发中使用mybatis 你会发现其实无论数据库的事务隔离级别是什么，你一个事务中多次查询同一个语句你会得到相同的结果，因为mybatis默认的一级缓存是基于sqlsession 的 所以只要你语句和参数没有变化就会的到相同的结果，所以在上述的场景中你将不会获得记录6 ，你的程序可能会产生意向不到的bug。