理解数据库事务隔离级别

一、SQL标准事务隔离级别解释

       在SQL标准中定义了四种隔离级别,每一种级别都规定了一个事务中所做的修改,较低级别的事务隔离通常可以执行更高的并发,系统开销也更低

四种隔离级别

READ UNCOMMITTED(未提交读)

       事务中的修改,即使没有提交,对其他事务也都是可见的,事务可以读取未提交的数据,也被称为脏读(Dirty Read)。这个级别会导致很多问题,从性能上来说也不会比其他隔离级别好很多,但却缺乏其他级别的很多好处,一般实际应用中很少用,甚至有些数据库内部根本就没有实现

READ COMMITTED(提交读)

       事务从开始直到提交之前,所做的任何修改对其他事务都是不可见的,这个级别有时候也叫做不可重复读(Nonrepeatable Read),因为同一事务中两次执行同样的查询,可能会得到不一样的结果

REPEATABLE READ(可重复读)

       同个事务中多次查询结果是一致的,解决了不可重复读的问题。此隔离级别下还是无法解决另外一个幻读(Phantom Read)的问题,幻读是指当某个事务在读取某个范围内的记录时,另外一个事务又在该范围内插入了新的记录,之前的事务再次读取该范围的记录时,会产生幻行

SERIALIZABLE(可串行化)

       SERIALIZABLE是最高的事务隔离级别,在该隔离下,强制事务串行执行。简单来说该级别下会在读取的每一行数据上都加上锁,可想而知新能会受到多大影响,当然部分数据库做了很好的优化,可以使得该级别下和REPEATABLE READ下的性能差不多

二、MySQL和PostgreSQL的不同

       需要指出的是,不同的数据库厂商对于事务隔离级别的实现是有差别的,不同的存储引擎(InnoDB就是一种存储引擎)对于事务的处理也都是有差异的,在近些年为了适应高并发,部分数据在内部还实现了MVCC(多版本并发控制)

默认隔离级别

       MySQL是REPEATABLE READ

       PostgreSQL是READ COMMITTED

内部实现

       MySQL四种隔离级别都实现了

       PostgreSQL内部只实现了其中两种,即READ COMMITTED和SERIALIZABLE,而显示使用READ UNCOMMITTED 和REPEATABLE READ都将自动提升一个隔离级别

MVCC的改进

       为了应对频繁的读写操作,MySQL和PostgreSQL都引入了MVCC,不得不说MVCC带来的性能提升是显著的,所谓MVCC即是指,在数据存储引入版本的概念,使得在数据操作时读和写可以同步进行

       MySQL(InnoDB和XtraDB)在引入MVCC后,在REPEATABLE READ模式下也不会存在幻读的问题,因为在MVCC下同一个事务中MySQL只会读取当前事务版本号以前的数据,所以后面插入的数据也不会影响当前读取,( MySQL默认使用REPEATABLE READ也有部分是这个),需要指出的是MySQL的MVCC只会在READ COMMITTED和REPEATABLE READ下工作

       PostgreSQL在SERIALIZABLE下MVCC也是工作的,但是它实现的SERIALIZABLE并不是真正的顺序执行事务,而是模拟的,也就是说在写入的时候还是可以查询数据(数据快照),只有在写写的情况下才会阻塞,所以不要以为PostgreSQL的SERIALIZABLE性能很差

三、事务隔离级别的验证

1、MySQL验证未提交读

按照步奏执行会发现还未commit的数据可以被查询到

2、MySQL验证不可重复读

按照步奏执行会发现同一个事务中两次相同查询返回数据不一样

3、MySQL两个会话不同事务隔离级别会怎样,以读未提交与读已提交实验

可以发现左边未提交读的事务依然可以读到右边隔离级别为提交读的未提交的数据

3、MySQL提交读在当前事务内部是否可以读取到未提交的数据

验证发现是可以读取到自己提交的数据

4、验证读读,读写,写读,写写的阻塞情况

MySQL隔离级别为可重复读

可以发现只有写写的情况下才会阻塞,这得益于MVCC技术的使用

MySQL隔离级别为可串行化

可以发现除了读读以外都会被阻塞

       MySQL的SERIALIZABLE是没有使用MVCC的所以在读写和写读的时候都是给数据加了排他锁,这时只能等待上一个事务完成

PostgreSQL隔离级别为可串行化

可以发现只有写写才会阻塞(新版PostgreSQL不能关闭自动提交,所以显示使用begin)

       PostgreSQL的SERIALIZABLE跟MySQL的REPEATABLE READ有点相似,在写读和读写的时候不会阻塞(在MVCC解决了幻读,SERIALIZABLE其实没多大必要去阻塞读写和写读),需要注意的是MySQL同时写可以顺序执行事务,但是PostgreSQL在第二个事务去执行时,如果第一个事务修改了数据并提交,这时第二事务会抛出错误:[Err] ERROR: could not serialize access due to concurrent update

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 211,265评论 6 490
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,078评论 2 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 156,852评论 0 347
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,408评论 1 283
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,445评论 5 384
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,772评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,921评论 3 406
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,688评论 0 266
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,130评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,467评论 2 325
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,617评论 1 340
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,276评论 4 329
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,882评论 3 312
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,740评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,967评论 1 265
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,315评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,486评论 2 348

推荐阅读更多精彩内容