MySQL事务隔离级别

在MySQL中，实现了这四种隔离级别，分别有可能产生问题以下所示：

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

表结构

而后往表中插入两条数据，插入后结果以下：

数据

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

一. 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后才会更新到数据库。

二. 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同一个事务中，读取到两次不一样的结果。这就形成了不可重复读，就是两次读取的结果不一样。这种现象叫不可重复读。

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

如今有个需求，就是老板说在同一个事务中查询结果必须保持一致，若是你是数据库，你会怎么作？数据库是这么作的。

在会话B中咱们当前事务隔离级别为repeatable read。具体操做以下：

set session transaction isolation level repeatable read;
start transaction;

接着在会话B中查询数据：

 

repeatablereadB1

咱们在A用户所在会话中为表account添加一条数据：

insert into account(id,account) value(3,1000);
commit;

而后咱们查询看数据插入是否成功：

 

repeatable readA

回到B用户所在的会话，咱们查询结果：

 

repeatablereadB2

用户B在他所在的会话中想插入一条新数据id=3，value=1000。来咱们操做下：

 

readpeatablereadB3

什么？居然插不进去，说我数据重复？

用户B固然不服啊，由于查询到数据只有两条啊，为何插入id=3说我数据重复了呢？

我再看一遍，莫非我眼花了？

 

repeatablereadB2

试想一下，在实际中用户A和用户B确定是相互隔离的，彼此不知道操做什么。用户B碰到这种现象，确定会炸毛的啊，明明不存在的数据，插入却说主键id=3数据重复了。

结论三：

当咱们将当前会话的隔离级别设置为repeatable read的时候，当前会话能够重复读，就是每次读取的结果集都相同，而无论其余事务有没有提交。

有什么问题吗？

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

四. 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的时候，其余会话对该表的写操做将被挂起。能够看到，这是隔离级别中最严格的，可是这样作势必对性能形成影响。因此在实际的选用上，咱们要根据当前具体的状况选用合适的。