重温数据库知识

知识点问题

1.什么可重复读？
2.什么幻读？
3.为什么innodb在RR隔离级别下能解决幻读？
4.mvcc是什么鬼？

三个问题：

脏读 、 不可重复读， 幻读；

四个隔离级别：

未提交读-RU
读已提交-RC
可重复读-RR
串行读-Serializable

事务特性

ACID

默认事务隔离级别

oracel - RC
mysql(innodb) - RR

mvcc是什么鬼？

InnoDB 在实现 MVCC 时用到的一致性读视图，即 consistent read view，用于支持 RC（Read Committed，读提交）和 RR（Repeatable Read，可重复读）隔离级别的实现
结论很清晰MVCC是用来实现RC, RR隔离级别的； 同时也表征了MVCC不能用来解决幻读；

一致性读是何时启动的？

1. 开启事务后的第一条sql语句就开启；
   2.start transaction with consistent snapshot 时创建的。

“快照”在 MVCC 里是怎么工作的？

背景介绍：

1. InnoDB 里面每个事务有一个唯一的事务 ID，叫作 transaction id；它是在事务开始的时候向 InnoDB 的事务系统申请的，是按申请顺序严格递增的。

2.*每行数据也都是有多个版本的。每次事务更新数据的时候，都会生成一个新的数据版本，并且把 transaction id 赋值给这个数据版本的事务 ID，记为 row trx_id。

image.png

3.语句更新会生成 undo log（回滚日志）， 如上的视图其它是靠 undo log来计算来实现，其实并不存在；

流程介绍

1.创建视图数组
InnoDB 为每个事务构造了一个数组，用来保存这个事务启动瞬间，当前正在“活跃”的所有事务 ID。“活跃”指的就是，启动了但还没提交；

数组里面事务 ID 的最小值记为低水位，当前系统里面已经创建过的事务 ID 的最大值加 1 记为高水位。

image.png

这样，对于当前事务的启动瞬间来说，一个数据版本的 row trx_id，有以下几种可能：
如果落在绿色部分，表示这个版本是已提交的事务或者是当前事务自己生成的，这个数据是可见的；
如果落在红色部分，表示这个版本是由将来启动的事务生成的，是肯定不可见的；
如果落在黄色部分，那就包括两种情况:
a. 若 row trx_id 在数组中，表示这个版本是由还没提交的事务生成的，不可见；
b. 若 row trx_id 不在数组中，表示这个版本是已经提交了的事务生成的，可见。

之前很久一段时间纠结在 黄色部分-b上不明白，其实还是没有仔细理解说明 中 启动了但还没提交 这几个字；

举例：
现在有活跃事务 100，事务A:事务号-101，事务B:事务号-102，事务C:事务号-104，事务D:事务号-105；（注意这里特别设计少了103）其中已事务D的视角来看，其视图数据为【100,101，102，104，105】, 103这个事务没有找到说明103已经提交了，已经不在“活跃”了， 故属于黄色部分-b这种情况；

更加具体的描述为：

版本未提交，不可见；
版本已提交，但是是在视图创建后提交的，不可见；
版本已提交，而且是在视图创建前提交的，可见

2.按照上面的规则，一步一步地执行数据的undo log就能读到在相当隔离级别的数据了；

特别注意，在MVCC场景下读分为两种

1.快照读； （为了满足RC, RR）
2.当前读； (为了不丢失已提交的数据)

image.png

如上在事务B中的update操作或select...for update这类的都属于当前读， 我们假设一下，如果不是当前读那么事务C已提交k=k+1就会丢失；

事务的可重复读的能力是怎么实现的？

可重复读相当于是快照读；

可重复读的核心就是一致性读（consistent read）；而事务更新数据的时候，只能用当前读。如果当前的记录的行锁被其他事务占用的话，就需要进入锁等待。

而读提交的逻辑和可重复读的逻辑类似，它们最主要的区别是：

在可重复读隔离级别下，只需要在事务开始的时候创建一致性视图，之后事务里的其他查询都共用这个一致性视图；
在读提交隔离级别下，每一个语句执行前都会重新算出一个新的视图。

什么是幻读？ 以及幻读会导致什么问题（所以才需要解决）

幻读仅专指“新插入的行”，其它事务在未提交前就已经读到（注意：更新是允许的吗？）

直接说结论： 在可重复读的基础上，加上锁 innodb解决了幻读的问题，（也特别强调： 间隙锁是在可重复读隔离级别下才会生效的，你如果把隔离级别设置为读提交的话，就没有间隙锁了）

更新操作是不可能成功的，会被行锁阻塞
新增操作也是不可能成功，会被gap lock, insert intention阻塞；

先说幻读会引起的问题，假如没有上面的锁的情况，视角扩大在主从同步上；

image.png

从库接收到事务操作为如下：

update t set d=5 where id=0; /*(0,0,5)*/
update t set c=5 where id=0; /*(0,5,5)*/
insert into t values(1,1,5);/*(1,1,5)*/
update t set c=5 where id=1; /*(1,5,5)*/

// 事务A
update t set d=100 where d=5;/*所有d=5的行，d改成100*/

由于可以看出在主库上结果是(0,5,5)， (1,5,5) ， 而在 通过binlog或其它同步方式， 从库上 (0,5,100) (1,5,100)

为什么要引入Gap Lock ?

上例的结论 即使锁住了所有的行还是解决不了插入的问题；

死锁分析例子

image.png

读提交隔离级别加 binlog_format=row 的组合问题