oppo后端16连问(三)

发布于 2022-5-16 18:03
浏览
0收藏

8. 数据库隔离级别是否了解?你们的数据库默认隔离级别是?为什么选它?


四大数据库隔离级别,分别是读未提交,读已提交,可重复读,串行化(Serializable)

 

 •  读未提交:事务即使未提交,却可以被别的事务读取到的,这级别的事务隔离有脏读、重复读、幻读的问题。
 •  读已提交:当前事务只能读取到其他事务提交的数据,这种事务的隔离级别解决了脏读问题,但还是会存在不可重复读、幻读问题;
 •  可重复读:限制了读取数据的时候,不可以进行修改,所以解决了不可重复读的问题,但是读取范围数据的时候,是可以插入数据,所以还会存在幻读问题。
 •  串行化:事务最高的隔离级别,在该级别下,所有事务都是进行串行化顺序执行的。可以避免脏读、不可重复读与幻读所有并发问题。但是这种事务隔离级别下,事务执行很耗性能。

 

MySQL选择Repeatable Read(可重复读)作为默认隔离级别,我们的数据库隔离级别选的是读已提交。

 

8.1 为什么MySQL的默认隔离离别是RR?


binlog的格式也有三种:statement,row,mixed。设置为statement格式,binlog记录的是SQL的原文。又因为MySQL在主从复制的过程是通过binlog进行数据同步,如果设置为读已提交(RC)隔离级别,当出现事务乱序的时候,就会导致备库在 SQL 回放之后,结果和主库内容不一致。

 

比如一个表t,表中有两条记录:

CREATE TABLE t (  
     a int(11) DEFAULT NULL,  
     b int(11) DEFAULT NULL,  
     PRIMARY KEY a (a),
     KEY b(b)
   ) ENGINE=InnoDB DEFAULT CHARSET=latin1;  
   insert into t1 values(10,666),(20,233); 

两个事务并发写操作,如下:oppo后端16连问(三)-开源基础软件社区读已提交(RC)隔离级别下,两个事务执行完后,数据库的两条记录就变成了(30,666)、(20,666)。这两个事务执行完后,binlog也就有两条记录,因为事务binlog用的是statement格式,事务2先提交,因此update t set b=666 where b=233优先记录,而update t set a=30 where b=666记录在后面。

 

bin log同步到从库后,执行update t set b=666 where b=233update t set a=30 where b=666记录,数据库的记录就变成(30,666)、(30,666),这时候主从数据不一致啦。

 

因此MySQL的默认隔离离别选择了RR而不是RCRR隔离级别下,更新数据的时候不仅对更新的行加行级锁,还会加间隙锁(gap lock)。事务2要执行时,因为事务1增加了间隙锁,就会导致事务2执行被卡住,只有等事务1提交或者回滚后才能继续执行。

 

并且,MySQL还禁止在使用statement格式的binlog的情况下,使用READ COMMITTED作为事务隔离级别。

 

我们的数据库隔离级别最后选的是读已提交(RC)。


那为什么MySQL官方默认隔离级别是RR,而有些大厂选择了RC作为默认的隔离级别呢?

 

 •  提升并发


RC 在加锁的过程中,不需要添加Gap LockNext-Key Lock 的,只对要修改的记录添加行级锁就行了。因此RC的支持的并发度比RR高得多,

 

 •  减少死锁


正是因为RR隔离级别增加了Gap LockNext-Key Lock 锁,因此它相对于RC,更容易产生死锁。

 

9. RR隔离级别实现原理,它是如何解决不可重复读的?


9.1 什么是不可重复读


先回忆下什么是不可重复读。假设现在有两个事务A和B:

 

 •  事务A先查询Jay的余额,查到结果是100
 •  这时候事务B 对Jay的账户余额进行扣减,扣去10后,提交事务
 •  事务A再去查询Jay的账户余额发现变成了90
oppo后端16连问(三)-开源基础软件社区事务A被事务B干扰到了!在事务A范围内,两个相同的查询,读取同一条记录,却返回了不同的数据,这就是不可重复读

 

9.2 undo log版本链 + Read View可见性规则


RR隔离级别实现原理,就是MVCC多版本并发控制,而MVCC是是通过Read View+ Undo Log实现的,Undo Log 保存了历史快照,Read View可见性规则帮助判断当前版本的数据是否可见。

 

Undo Log版本链长这样:oppo后端16连问(三)-开源基础软件社区Read view 的几个重要属性

 

 •  m_ids:当前系统中那些活跃(未提交)的读写事务ID, 它数据结构为一个List。
 •  min_limit_id:表示在生成Read View时,当前系统中活跃的读写事务中最小的事务id,即m_ids中的最小值。
 •  max_limit_id:表示生成Read View时,系统中应该分配给下一个事务的id值。
 •  creator_trx_id: 创建当前Read View的事务ID

 

Read view 可见性规则如下:

 

1.如果数据事务IDtrx_id < min_limit_id,表明生成该版本的事务在生成Read View前,已经提交(因为事务ID是递增的),所以该版本可以被当前事务访问。
2.如果trx_id>= max_limit_id,表明生成该版本的事务在生成Read View后才生成,所以该版本不可以被当前事务访问。
3.如果min_limit_id =<trx_id< max_limit_id,需要分3种情况讨论


 •  3.1 如果m_ids包含trx_id,则代表Read View生成时刻,这个事务还未提交,但是如果数据的trx_id等于creator_trx_id的话,表明数据是自己生成的,因此是可见的。
 •  3.2 如果m_ids包含trx_id,并且trx_id不等于creator_trx_id,则Read View生成时,事务未提交,并且不是自己生产的,所以当前事务也是看不见的;
 •  3.3 如果m_ids不包含trx_id,则说明你这个事务在Read View生成之前就已经提交了,修改的结果,当前事务是能看见的。

 

9.3 RR 如何解决不可重复读


查询一条记录,基于MVCC,是怎样的流程

 

1.获取事务自己的版本号,即事务ID
2.获取Read View
3.查询得到的数据,然后Read View中的事务版本号进行比较。
4.如果不符合Read View的可见性规则, 即就需要Undo log中历史快照;
5.最后返回符合规则的数据


假设存在事务A和B,SQL执行流程如下oppo后端16连问(三)-开源基础软件社区在可重复读(RR)隔离级别下,一个事务里只会获取一次Read View,都是副本共用的,从而保证每次查询的数据都是一样的。

 

假设当前有一张core_user表,插入一条初始化数据,如下:

oppo后端16连问(三)-开源基础软件社区

 基于MVCC,我们来看看执行流程

 

1.A开启事务,首先得到一个事务ID为100
2.B开启事务,得到事务ID为101
3.事务A生成一个Read View,read view对应的值如下
oppo后端16连问(三)-开源基础软件社区然后回到版本链:开始从版本链中挑选可见的记录:oppo后端16连问(三)-开源基础软件社区由图可以看出,最新版本的列name的内容是孙权,该版本的trx_id值为100。开始执行read view可见性规则校验:

min_limit_id(100)=<trx_id(100)<102;
creator_trx_id = trx_id =100;

由此可得,trx_id=100的这个记录,当前事务是可见的。所以查到是name为孙权的记录。

 

4.事务B进行修改操作,把名字改为曹操。把原数据拷贝到undo log,然后对数据进行修改,标记事务ID和上一个数据版本在undo log的地址。
oppo后端16连问(三)-开源基础软件社区5.事务B提交事务


6.事务A再次执行查询操作,因为是RR(可重复读)隔离级别,因此会复用老的Read View副本,Read View对应的值如下
oppo后端16连问(三)-开源基础软件社区然后再次回到版本链:从版本链中挑选可见的记录:oppo后端16连问(三)-开源基础软件社区从图可得,最新版本的列name的内容是曹操,该版本的trx_id值为101。开始执行read view可见性规则校验:

min_limit_id(100)=<trx_id(101)<max_limit_id(102);
因为m_ids{100,101}包含trx_id(101),
并且creator_trx_id (100) 不等于trx_id(101)

所以,trx_id=101这个记录,对于当前事务是不可见的。这时候呢,版本链roll_pointer跳到下一个版本,trx_id=100这个记录,再次校验是否可见:

min_limit_id(100)=<trx_id(100)< max_limit_id(102);
因为m_ids{100,101}包含trx_id(100),
并且creator_trx_id (100) 等于trx_id(100)

所以,trx_id=100这个记录,对于当前事务是可见的,所以两次查询结果,都是name=孙权的那个记录。即在可重复读(RR)隔离级别下,复用老的Read View副本,解决了不可重复读的问题。

 

大家可以回头多看几遍我这篇文章哈:看一遍就理解:MVCC原理详解

标签
已于2022-5-16 18:03:56修改
收藏
回复
举报
回复
添加资源
添加资源将有机会获得更多曝光,你也可以直接关联已上传资源 去关联
    相关推荐