oppo后端16连问（三）

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); 

两个事务并发写操作，如下：在读已提交（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=233和update t set a=30 where b=666记录，数据库的记录就变成（30,666）、(30,666)，这时候主从数据不一致啦。

 

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

 

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

 

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

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

 

 •  提升并发

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

 

 •  减少死锁

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

 

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

9.1 什么是不可重复读

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

 

 •  事务A先查询Jay的余额，查到结果是100
 •  这时候事务B 对Jay的账户余额进行扣减，扣去10后，提交事务
 •  事务A再去查询Jay的账户余额发现变成了90
事务A被事务B干扰到了！在事务A范围内，两个相同的查询，读取同一条记录，却返回了不同的数据，这就是不可重复读。

 

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

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

 

Undo Log版本链长这样：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执行流程如下在可重复读（RR）隔离级别下，一个事务里只会获取一次Read View，都是副本共用的，从而保证每次查询的数据都是一样的。

 

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

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

 

1.A开启事务，首先得到一个事务ID为100
2.B开启事务，得到事务ID为101
3.事务A生成一个Read View，read view对应的值如下
然后回到版本链：开始从版本链中挑选可见的记录：由图可以看出，最新版本的列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的地址。
5.事务B提交事务

6.事务A再次执行查询操作，因为是RR（可重复读）隔离级别，因此会复用老的Read View副本，Read View对应的值如下
然后再次回到版本链：从版本链中挑选可见的记录：从图可得，最新版本的列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原理详解