【事务隔离级别】——深度探索数据库的事务隔离级别

素颜马尾好姑娘i 2022-08-20 02:15 170阅读 0赞

设置事务隔离级别的方式有很多种，上篇文章中只简单提到了理论知识，这里数据库以MySQL为例，来动手设置一下事务的隔离级别并观察一下事务的隔离级别到底起到什么作用。

我们都知道，每启动一下MySQL，就会获得一个数据库连接，每个数据库连接有一个全局变量@@tx\_isolation，表示当前连接中事务的隔离级别。

**查看事务隔离级别**

命令行登录mysql，查看当前事务隔离级别：

select @@tx_isolation;

或者

select @@session.tx_isolation;

![这里写图片描述][20160125161146289]

可以看到mysql默认的事务隔离级别为REPEATABLE-READ

查看系统全局事务离级别可以用：

select @@global.tx_isolation;

**设置事务隔离级别**

设置当前事务隔离级别

set session transaction isolation level repeatable read;

设置系统全局（默认）事务隔离级别

set global transaction isolation level repeatable read;

**read uncommitted测试**

打开一个客户端A，并设置当前事务模式为read uncommitted（未提交读），查询表account的初始值：

![这里写图片描述][20160126111325889]

在客户端A的事务提交之前，打开另一个客户端B，更新表account：

![这里写图片描述][20160126111216814]

这时，虽然客户端B的事务还没提交，但是客户端A就可以查询到B已经更新的数据：

![这里写图片描述][20160126111631265]

一旦客户端B的事务因为某种原因回滚，所有的操作都将会被撤销，那客户端A查询到的数据其实就是脏数据：

![这里写图片描述][20160126111847032]

**read committed测试**

针对上面的问题，把客户端A的事务隔离级别设置为read committed，再重复上面的步骤，会发现B在事务结束之前，A并不能查询到B所做的操作。

客户端A的执行结果

![这里写图片描述][20160126141448108]

客户端B的执行结果

![这里写图片描述][20160126144143348]

但是正如上文所说，这种隔离级别下可能导致前事务中多次读取特定记录的结果不相同，比如客户端A事务隔离级别为read committed，在A的一个事务中，执行两次相同的查询，在这两次查询的中间，客户端B对数据进行更改并提交事务，那么会导致客户端A的两次查询结果不一致，导致“不可重复读”的麻烦。

客户端A的执行结果

![这里写图片描述][20160126164149736]

客户端B的执行结果

![这里写图片描述][20160126164200486]

**repeatable read测试**

同理，如果设置了repeatable read隔离级别，就可以保证在当前事务中多次执行相同查询的结果集相同，实现“可重复读”。

同样以客户端A设置事务隔离级别为repeatable read为例，执行结果如下：

客户端A的执行结果

![这里写图片描述][20160126171458571]

客户端B的执行结果

![这里写图片描述][20160126171507930]

上篇文章说到，这种隔离级别会导致“幻读”，比如客户端A中事务操作表中符合条件的若干行，同时客户端B中事务插入符合A操作条件的数据行，然后再提交。究竟会发生什么nie~~

小编为此也进行了测试：

客户端A的执行结果  
![这里写图片描述][20160126195532439]

客户端B的执行结果

![这里写图片描述][20160126195548567]

结果却不像我们预测的那样，为客户端A中的事务设置隔离级别为repeatable read，但在客户端B中的事务插入数据后，A并没有出现“幻读”的现象。查了资料才知道，原来在mysql中，不会出现幻读。mysql的实现和标准定义的RR隔离级别有差别。

当然，  
　　上篇文章说到的只是SQL规范所规定的标准，不同的数据库具体的实现可能会有些差异，所以还是以实际为准~~  
　　实践出真知，所以每接触到一些理论知识时，最好能够实践一把，自己动手去探索，总会带给你意想不到的收货哦。

[20160125161146289]: /images/20220731/2da964f1cdb14d07b611010d087f9a58.png
[20160126111325889]: /images/20220731/09176720d1724ef2a33b1b1857520866.png
[20160126111216814]: /images/20220731/7b74363daef44f86bdc2350fb2a2f0c4.png
[20160126111631265]: /images/20220731/e6086821bb7a4b7f8f5afe3cb932ce01.png
[20160126111847032]: /images/20220731/b7fdbc2be39f4113a805bb01585f869c.png
[20160126141448108]: /images/20220731/de3e2f3afe96422a8cfcce381d50b92a.png
[20160126144143348]: /images/20220731/ec795d1660274b78a5f05817501ea202.png
[20160126164149736]: /images/20220731/e79292c42b2c44359ab1c99839788542.png
[20160126164200486]: /images/20220731/ee7850b236cc4d6bbe9bacfe35048f38.png
[20160126171458571]: /images/20220731/2ccfbf696f204a4395754128b42f6286.png
[20160126171507930]: /images/20220731/efa13a05939c4ce1baf575114fa363cc.png
[20160126195532439]: /images/20220731/45708a069a2d44ebb61aa806efd59ee8.png
[20160126195548567]: /images/20220731/ea70baac0a89449097800db443d30a5c.png