最近刚好闲下来,自己事务隔离级别不是太熟悉,所以写篇文章记录下来。
SQL定义了四类隔离级别,包括了一些具体规则,用来限定事务内外的哪些改变是可见的,哪些是不可见的。低级别的隔离级一般支持更高的并发处理,并拥有更低的系统开销。
其次我们先了解下这四类隔离级别的定义:
Read Uncommitted(读取未提交内容)
在该隔离级别,所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用,因为它的性能也不比其他级别好多少。读取未提交的数据,也被称之为脏读(Dirty Read)。
Read Committed(读取提交内容)
这是大多数数据库系统的默认隔离级别(但不是MySQL默认的)。它满足了隔离的简单定义:一个事务只能看见已经提交事务所做的改变。这种隔离级别 也支持所谓的不可重复读(Nonrepeatable Read),因为同一事务的其他实例在该实例处理其间可能会有新的commit,所以同一select可能返回不同结果。
Repeatable Read(可重读)
这是MySQL的默认事务隔离级别,它确保同一事务的多个实例在并发读取数据时,会看到同样的数据行。不过理论上,这会导致另一个棘手的问题:幻读 (Phantom Read)。简单的说,幻读指当用户读取某一范围的数据行时,另一个事务又在该范围内插入了新行,当用户再读取该范围的数据行时,会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制(MVCC,Multiversion Concurrency Control)机制解决了该问题。
Serializable(可串行化)
这是最高的隔离级别,它通过强制事务排序,使之不可能相互冲突,从而解决幻读问题。简言之,它是在每个读的数据行上加上共享锁。在这个级别,可能导致大量的超时现象和锁竞争。
这四种隔离级别采取不同的锁类型来实现,若读取的是同一个数据的话,就容易发生问题。例如:
脏读(Drity Read):某个事务已更新一份数据,另一个事务在此时读取了同一份数据,由于某些原因,前一个RollBack了操作,则后一个事务所读取的数据就会是不正确的。
不可重复读(Non-repeatable read):在一个事务的两次查询之中数据不一致,这可能是两次查询过程中间插入了一个事务更新的原有的数据。
幻读(Phantom Read):在一个事务的两次查询中数据笔数不一致,例如有一个事务查询了几列(Row)数据,而另一个事务却在此时插入了新的几列数据,先前的事务在接下来的查询中,就会发现有几列数据是它先前所没有的
在MySQL中,实现这四类隔离级别,分别有可能产生问题如下所示:
下面,利用MySQL来演示以上这四类隔离级别,首先需要知道以下指令的含义:
SELECT @@global.tx_isolation; //全局,从对那个点开始的所有链接
SELECT @@session.tx_isolation; //当前连接上执行的事务设置默认事务级别
SELECT @@tx_isolation;//是为下一个(未开始)事务设置隔离级别
set global transaction isolation level read committed;//全局事务隔离级别
set session transaction isolation level read committed;//当前链接事务隔离级别
首先我创建tx表,如图所示
然后分别对其四类事务级别逐一分析,具体如下:
一)、将A的隔离级别设置为read uncommitted(未提交读)
客户端A
客户端B更新数据
客户端A
从上面的实验可以看出,客户端B更新了一条记录,但是没有提交,此时客户端A可以查询出未提交记录。造成脏读现象。未提交读是最低的隔离级别。
二)、将客户端A的事务隔离级别设置为read committed(已提交读)
客户端A
客户端B,进行更新数据
然后,客户端A查询结果,第一次查询是在commit之前其结果集无变化,第二次查询是在commit之后,其结果集发生变化
由此可以看出,已提交读隔离级别解决了脏读的问题,但是出现了不可重复读的问题,即事务A在两次查询的数据不一致,因为在两次查询之间事务B更新了一条数据。已提交读只允许读取已提交的记录,但不要求可重复读。
(三)、将A的隔离级别设置为repeatable read(可重复读)
客户端A,将隔离级别设置为可重复读,然后开启事务,进行查询
客户端B,开启事务,并进行修改
此时查看客户端A,进行查询数据并未改变
此时B提交事务,并查询
然后查看A,数据还是没有变化
A进行commit之后,发现数据改变了
由以上可以得出,可重复读隔离级别只允许读取已提交记录,而且在一个事务两次读取一个记录期间,其他事务不能更新该记录。但该事务不要求与其他事务可串行化。例如,当一个事务可以找到由一个已提交事务更新的记录,但是可能产生幻读问题(注意是可能,因为数据库对隔离级别的实现有所差别)。像以上的实验,就没有出现数据幻读的问题。
继续验证,A开启事务,并对其修改
B开启事务,并对其进行修改,修改被挂起,直到超时,但对另外一条的修改却可以成功,说明客户端A在对其修改的时候,对表加上了行共享锁。
在事务中对某条记录作修改时,会对记录加上行共享锁,直到结束才释放。
(四)、将A的隔离级别设置为 可串行化 (Serializable)
客户端A,首先设置隔离级别
然后开启事务,进行查询
此时打开客户端B,进行查询,发现可以正常查询
此时开启事务,对客户端B进行修改update操作,B开启事务,并对记录作修改,此时由于A并未提交,所以B一直处于等待的状态,直到最后超时。说明事务A做对表进行做查询的时候,对表加上了共享锁!
serializable完全锁定字段,若一个事务来查询同一份数据就必须等待,直到前一个事务完成并解除锁定为止 。是完整的隔离级别,会锁定对应的数据表格,因而会有效率的问题。