我是靠谱客的博主 怕黑橘子,最近开发中收集的这篇文章主要介绍深入解析MySQL的事务隔离及其对性能产生的影响,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

 SQL标准定义了4类隔离级别,包括了一些具体规则,用来限定事务内外的哪些改变是可见的,哪些是不可见的。低级别的隔离级一般支持更高的并发处理,并拥有更低的系统开销。
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中,实现了这四种隔离级别,分别有可能产生问题如下所示:

20151219142625513.jpg (838×267)
MySQL事务隔离级别对其性能的影响
MySQL默认工作在级别三下。我们知道事务隔离是为了避免并发操作相互影响而导数据的不一致性。所以为了保证数据的一致性,就引入了事务隔离的功能。以上四个级别的对数据的一致性保护是逐步提高的。级别4对事务的隔离效果最好,但是性能最差,一般不再生产环境中使用。
下面通过实例来检验不同级别下MySQL性能收到的影响。我的实验环境是:Redhat5.8+MySQL5.5
首先我们这里启用两个session:
1、验证级别一的特性
我们在session A上进行的操作为:

20151219142742629.jpg (439×108)

在session B上的操作同session A,这里不再附上截图。
       接下来我们就通过一系列的实验来观察READ-UNCOMMITTED到底是什么,它到底有什么特性,对我们的操作到底有什么影响。首先,我们可以看到表中的初始数据如下:

20151219142759392.jpg (396×309)

接下来我们在sessionA上更改其中的一条记录,更改结果如下:

20151219142836127.jpg (449×393)

注意:我们在上面启用了事务,但是我们在这里并没有进行commit操作。
 
接下来我们在sessionB中对刚才改过的表进行select查询,查询结果如下:

20151219142857081.jpg (393×258)

我们可以清楚的看到,虽然我们并没有对session A的结果进行commit,但是结果确实已经改变。因此在这种级别下,没有提交的操作会对数据的一致性有影响。因此,如果我们此时在session A上对上述操作进行回滚,我们会发现此时session B上的结果又回到原来最初的结果,这样就造成了数据的不一致性,这也称为数据的幻读现象,看起来是很诡异的事情。因此在某些场景下,我们应该避免这种现象的产生。但是这种级别也不是没有它的用武之地,比如当我们有大量数据需要写入,而读操作很少的时候,就适合用这种模式。
可以看到session A回滚后,session B中的数据又变成最初的样子,这也称为幻读:

20151219142930549.jpg (388×285)

2、验证级别READ COMMITTED特性
       首先把session A和session B的隔离级别都改为READ-COMMITTED,并且全部都开启事务,操作如下:

20151219142953399.jpg (419×106)

接下来我们查看tutors表的初始状态信息:

20151219143009635.jpg (389×273)

然后我们依然是对数据进行更新操作,更新之后仍然没有commit。我们可以看到在sessionA中,结果已经发生改变:

20151219143025324.jpg (447×356)

此时我们在session B中查看,发现结果依然维持不变:

20151219143041273.jpg (400×274)

但是,如果我们此时在session A中进行commit操作,我们就会发现,sessionB此时查询就会发生改变,这样也造成了数据的前后不一致性,也是数据的幻读:

20151219143129621.jpg (387×272)

3、数据的可重读
       数据的可重读,也叫作REPEATABLE-READ,这是MySQL默认采用的事务隔离级别,有其优势,但是仍然没有从根本上解决数据的一致性问题。首先,还是让我们来测试一下,在这种级别下MySQL到底是如何工作的,又有哪些特性,我们又该怎样去操作。
       我们先把REPEATABLE-READ的环境设置好,具体的操作方法如下:

20151219143145636.jpg (426×103)

然后我们在查看其初始数据,其结果如下:

20151219143201861.jpg (391×281)

我们在session A中修改数据,并进行commit,修改后的结果如下:

20151219143219960.jpg (394×285)

然后我们在session B中进行查看发现结果仍然没有任何改变:

20151219143235949.jpg (383×282)

这就是可重读的特性,只要本次会话不提交,尽管对方修改,但是结果仍然不变,只有在session B中也进行commit操作,所作的修改才会在sessionB中生效。
 
4、seriabliable
这个级别是事务隔离安全性最好的,但是也是性能最差的,因为这个级别所有的操作都是串行进行的。一个操作没有提交,另一个受到影响的操作会处于阻塞状态。
为了验证这种效果,我们先把环境设置好,具体为在session A和session B同时设置如下:

20151219143252378.jpg (400×100)

在session A 中对其任意字段进行修改,并且没有进行commit操作。此时挥发现sessionB中的查询操作会一直处于阻塞状态:

20151219143310329.jpg (298×55)

这就设串行化隔离的效果,也是为什么串行化隔离并发能力差的原因。

最后

以上就是怕黑橘子为你收集整理的深入解析MySQL的事务隔离及其对性能产生的影响的全部内容,希望文章能够帮你解决深入解析MySQL的事务隔离及其对性能产生的影响所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(86)

评论列表共有 0 条评论

立即
投稿
返回
顶部