设为首页 收藏本站
查看: 536|回复: 0

[经验分享] 浅析MySQL事务隔离级别对其性能的影响

[复制链接]
累计签到:1 天
连续签到:1 天
发表于 2015-3-27 09:32:28 | 显示全部楼层 |阅读模式
MySQL对事务的隔离级别共分为四个级别,分别是:
1.        READ UNCOMMITTED     读未提交
2.        READ COMMITTED       读提交
3.        REPEATABLE           可重读
4.        SERIALIABLE          可串读
MySQL默认工作在级别三下。我们知道事务隔离是为了避免并发操作相互影响而导数据的不一致性。所以为了保证数据的一致性,就引入了事务隔离的功能。以上四个级别的对数据的一致性保护是逐步提高的。级别4对事务的隔离效果最好,但是性能最差,一般不再生产环境中使用。
下面通过实例来检验不同级别下MySQL性能收到的影响。我的实验环境是:Redhat5.8+MySQL5.5
首先我们这里启用两个session:

1、验证级别一的特性我们在session A上进行的操作为:
%E7%BA%A7%E5%88%AB1_B.JPG
在session B上的操作同session A,这里不再附上截图。
       接下来我们就通过一系列的实验来观察READ-UNCOMMITTED到底是什么,它到底有什么特性,对我们的操作到底有什么影响。首先,我们可以看到表中的初始数据如下:
%E7%BA%A7%E5%88%AB1_C.JPG
接下来我们在sessionA上更改其中的一条记录,更改结果如下:
%E7%BA%A7%E5%88%AB1_D.JPG
注意:我们在上面启用了事务,但是我们在这里并没有进行commit操作。

接下来我们在sessionB中对刚才改过的表进行select查询,查询结果如下:
%E7%BA%A7%E5%88%AB1_E.JPG
我们可以清楚的看到,虽然我们并没有对session A的结果进行commit,但是结果确实已经改变。因此在这种级别下,没有提交的操作会对数据的一致性有影响。因此,如果我们此时在session A上对上述操作进行回滚,我们会发现此时session B上的结果又回到原来最初的结果,这样就造成了数据的不一致性,这也称为数据的幻读现象,看起来是很诡异的事情。因此在某些场景下,我们应该避免这种现象的产生。但是这种级别也不是没有它的用武之地,比如当我们有大量数据需要写入,而读操作很少的时候,就适合用这种模式。
可以看到session A回滚后,session B中的数据又变成最初的样子,这也称为幻读:
%E7%BA%A7%E5%88%AB1_F.JPG
2、验证级别READ COMMITTED特性       首先把session A和session B的隔离级别都改为READ-COMMITTED,并且全部都开启事务,操作如下:
%E7%BA%A7%E5%88%AB2_A.JPG

接下来我们查看tutors表的初始状态信息:
%E7%BA%A7%E5%88%AB2_B.JPG

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

此时我们在session B中查看,发现结果依然维持不变:
%E7%BA%A7%E5%88%AB2_D.JPG

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

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

然后我们在查看其初始数据,其结果如下:
%E7%BA%A7%E5%88%AB3_B.JPG

我们在session A中修改数据,并进行commit,修改后的结果如下:
%E7%BA%A7%E5%88%AB3_C.JPG

然后我们在session B中进行查看发现结果仍然没有任何改变:
%E7%BA%A7%E5%88%AB3_D.JPG
这就是可重读的特性,只要本次会话不提交,尽管对方修改,但是结果仍然不变,只有在session B中也进行commit操作,所作的修改才会在sessionB中生效。

4、seriabliable
这个级别是事务隔离安全性最好的,但是也是性能最差的,因为这个级别所有的操作都是串行进行的。一个操作没有提交,另一个受到影响的操作会处于阻塞状态。
为了验证这种效果,我们先把环境设置好,具体为在session A和session B同时设置如下:
%E7%BA%A7%E5%88%AB4_A.JPG
在session A 中对其任意字段进行修改,并且没有进行commit操作。此时挥发现sessionB中的查询操作会一直处于阻塞状态:
%E7%BA%A7%E5%88%AB4_B.JPG
这就设串行化隔离的效果,也是为什么串行化隔离并发能力差的原因。
实验测试用的数据我已经上传。


运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-51044-1-1.html 上篇帖子: MariaDB v10.0的安装过程 下篇帖子: 一键自动化安装MySQL服务端 隔离 影响
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表