MySQL - 说一下数据库的事务隔离

总结

spring 有五大隔离级别，默认值为 ISOLATION_DEFAULT（使用数据库的设置）;

其他四个隔离级别和数据库的隔离级别一致 (越往下隔离级别越高，花费越大)：

• read uncommited 未提交读：是最低的事务隔离级别。事务未提交前，数据就可被其他事务读取 --> 会造成：脏读、不可重复读、幻读
• read commited 提交读：一个事务提交后才能被其他事务读取到，SQL server 的默认级别 --> 会造成：不可重复读、幻读 
• repeatable read 可重复读：保证多次读取同一个数据时，其值都和事务开始时候的内容是一致，禁止读取到别的事务未提交的数据，MySQL 的默认级别 --> 会造成: 幻读。
• serializable 序列化：这是花费最高代价但最可靠的事务隔离级别。事务被处理为顺序执行。该隔离级别能防止脏读、不可重复读、幻读。

不可重复读 vs 幻读

设置repeatable read隔离后：事务A要两次读取表T的中数据，虽然设置 repeatable read 可以防止事务B对数据进行修改（修复可重复读），
但是事务B却可以向表T中插入新的数据（依然无法进制幻读）。

 

二、脏读、不可重复读、幻象读

• 脏读：表示一个事务能够读取另一个事务中还未提交的数据。比如，某个事务尝试插入记录 A，此时该事务还未提交，然后另一个事务尝试读取到了记录 A。因为这个记录 A还没有提交那么另外一个事务读取到的这个数据我们称之为脏数据。依据脏数据所做的操作肯能是不正确的。
• 不可重复读：指在一个事务内，多次读同一数据，但不一样。例如，事务1 读取 记录A， 事务1 还没有执行结束；此时另外一个 事务2 也访问 记录A，并修改了记录A。 那么在事务1 第两次读取记录A时，读到的数据可能是不一样的。这种情况被称为是不可重复读。
• 幻象读：指同一个事务内多次查询返回的结果集不一样。比如同一个事务 A 第一次查询时候有 n 条记录，但是第二次同等条件下查询却有 n+1 条记录，这就好像产生了幻觉。发生幻读的原因也是另外一个事务B新增或者删除或者修改了第一个事务A结果集里面的数据，同一个记录的数据内容被修改了，所有数据行的记录就变多或者变少了。因此幻读的必要条件是两个，第一是事务B有Insert/delete操作，第二个另一个事务A做了范围查询；

 

三、详细文章

好久没碰数据库了，只是想起自己当时在搞数据库的时候在事务隔离级别这块老是卡，似懂非懂的。现在想把这块整理出来，尽量用最简洁的语言描述出来，供新人参考。

首先创建一个表account。创建表的过程略过（由于InnoDB存储引擎支持事务，所以将表的存储引擎设置为InnoDB）。表的结构如下：

 

表结构

然后往表中插入两条数据，插入后结果如下：

 

数据

为了说明问题，我们打开两个控制台分别进行登录来模拟两个用户（暂且成为用户A和用户B吧），并设置当前MySQL会话的事务隔离级别。

3.1 read uncommitted（读取未提交数据）

具体用户A的操作如下：

set session transaction isolation level read uncommitted； start transaction; select * from account; 

结果如下：

 

数据

用户B的操作如下：

set session transaction isolation level read uncommitted；
start transaction;
update account set account=account+200 where id = 1;

随后我们在A用户中查询数据，结果如下：

 

uncommittedA数据

结论一：

我们将事务隔离级别设置为read uncommitted，即便是事务没有commit，但是我们仍然能读到未提交的数据，这是所有隔离级别中最低的一种。

那么这么做有什么问题吗？

那就是我们在一个事务中可以随随便便读取到其他事务未提交的数据，这还是比较麻烦的，我们叫脏读。我不知道这个名字是怎么起的，为了增强大家的印象，可以这么想，这个事务好轻浮啊，饥渴到连别人没提交的东西都等不及，真脏，呸！

实际上我们的数据改变了吗？

答案是否定的，因为只有事务commit后才会更新到数据库。

3.2 read committed（可以读取其他事务提交的数据）---大多数数据库默认的隔离级别

同样的办法，我们将用户B所在的会话当前事务隔离级别设置为read commited。

在用户A所在的会话中我们执行下面操作：

update account set account=account-200 where id=1;

 

read committed

我们将id=1的用户account减200。然后查询，发现id=1的用户account变为800。

在B用户所在的会话中查询：

select * from account； 

结果如下：

 

read committedB

我们会发现数据并没有变，还是1000。

接着在会话A中我们将事务提交：

commit;

在会话B中查询结果如下：

 

read committedB1

结论二：

当我们将当前会话的隔离级别设置为read committed的时候，当前会话只能读取到其他事务提交的数据，未提交的数据读不到。

那么这么做有什么问题吗？

那就是我们在会话B同一个事务中，读取到两次不同的结果。这就造成了不可重复读，就是两次读取的结果不同。这种现象叫不可重复读。

3.3 repeatable read（可重读）---MySQL默认的隔离级别

（注意：原文这部分的例子有误，遂删除）

结论三：

当我们将当前会话的隔离级别设置为repeatable read的时候，当前会话可以重复读，就是每次读取的结果集都相同，而不管其他事务有没有提交。

有什么问题吗？

管他呢，老板的要求满足了。要一个事务中读取的数据一致（可重复读）。我只能这么做啊，打肿脸装胖子。数据已经发生改变，但是我还是要保持一致。但是，出现了用户B面对的问题，这种现象叫幻读（记得当时就在这个地方纠结好久，到底什么是幻读啊）。

3.4 serializable（串行化）

同样，我们将用户B所在的会话的事务隔离级别设置为serializable并开启事务。

set session transaction isolation level serializable;
start transaction;

在用户B所在的会话中我们执行下面操作：

select * from account; 

结果如下：

 

serializableA

那我们这个时候在用户A所在的会话中写数据呢？

 

readcommittedA1

我们发现用户A所在的会话陷入等待，如果超时（这个时间可以进行配置），会出现Lock wait time out提示：

 

readcommittedA2

如果在等待期间我们用户B所在的会话事务提交，那么用户A所在的事务的写操作将提示操作成功。

结论四：

当我们将当前会话的隔离级别设置为serializable的时候，其他会话对该表的写操作将被挂起。可以看到，这是隔离级别中最严格的，但是这样做势必对性能造成影响。所以在实际的选用上，我们要根据当前具体的情况选用合适的。

参考文献

作者：伞U
链接：https://www.jianshu.com/p/4e3edbedb9a8
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。