事务并发问题及事务隔离级别的学习

╰+攻爆jí腚メ 2023-10-06 08:49 4阅读 0赞

以下内容都是看的咕泡学院的大神老师讲的一个公开课，就是记录一下。

#### 事务并发带来的三大问题 ####

##### 1、脏读 #####

如下图，左右两个事务A、B。事务A首先查询`id=1`的数据，得到`age=16`之后，事务B对`id=1`的数据，将`age=16`更新为`age=18`，然后事务A，再查询`id=1`的数据，这种在一个事务里边，多次读取同一条数据，该数据又是在其他事务中未提交的数据，同样的记录，但是得到的结果前后不一致，称为`脏读`。但是因为是没有提交的数据，将来的某个时间有可能事务B会回滚操作，导致`age`又重新变成`16`。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvaGFxaXlp_size_16_color_FFFFFF_t_70_pic_center]

##### 2、不可重复读 #####

与`脏读`的差别在于`不可重复读`是事务B中已经提交了数据。  
   `不可重复读`针对的是更新和删除，即`update`、`delete`。因为修改和删除，是操作的当前数据，并且已提交无法回滚，变化已经定型，已持久化到磁盘，所以叫`不可重复读`。  
   如下图，还是左右两个事务A、B。事务A首先查询`id=1`的数据，得到`age=16`之后，事务B对`id=1`的数据，将`age=16`更新为`age=18`，并且进行了`commit`，即提交了。然后事务A，再查询`id=1`的数据，读取的数据是`age=18`。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvaGFxaXlp_size_16_color_FFFFFF_t_70_pic_center 1]

##### 3、幻读 #####

幻读是针对`insert`语句，事务A执行一个范围查询，本来只有一条数据，但是经过事务B添加了一条数据后，导致再次查询变成了2条数据。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvaGFxaXlp_size_16_color_FFFFFF_t_70_pic_center 2]

`脏读`与`不可重复读`的区别在于是否提交，`脏读`意思是未提交，还没有持久化到磁盘，这种的数据有可能会回滚再变回原来的数据，而`不可重复读`就在与已提交的数据，以前的数据不可能再读回来的。  
   `insert`带来的问题不属于`不可重复读`，`insert`并没有动到以前的数据，也就是说数据一致性并没有破坏，是新增数据带来的其他事务读不一致问题。

#### 事务隔离级别 ####

事务并发带来的三大问题，其实就是数据库读一致性的问题，必须由数据库提供一定的事务隔离机制来解决。  
  事务隔离有如下级别，`SQL92 ANSI/ISO标准`通过定义四种隔离级别，来规范数据库厂商按照该功能提供解决不同级别的事务并发问题。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvaGFxaXlp_size_16_color_FFFFFF_t_70_pic_center 3]  
  如上图所示，一共有四种隔离级别。分别解决的如下图所示 问题：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvaGFxaXlp_size_16_color_FFFFFF_t_70_pic_center 4]  
   `mysql的InnoDB`中默认事务隔离级别是`可重复读(Repeatable Read)`,在InnoDB存储引擎中，`可重复读(Repeatable Read)`的隔离级别同时也解决了`幻读`问题。`InnoDB` 默认使用 RR 作为事务隔离级别的原因，既保证了数据的一致性，又支持较高的并发度。

#### 事务隔离级别的解决方案 ####

第一种即读取数据前对其加锁，阻止其他事务对数据进行修改，`Lock Based Concurrency Control`(LBCC)。这种方案导致的问题是，如果有人读取数据，不会允许其他事务进行修改，简单粗暴。

第二种即生成一个数据请求时间点的一致性数据快照（Snapshot）,并用这个快照提供一定级别（语句级和事务级）的一致性读取。即保证在一定时间内多次读取数据一致。

`InnoDb`中对于每行数据其实都隐藏了三个字段：

db_row_id:6字节，行标识
    db_trx_id:6字节，插入或更新行的最后一个事务id,自动递增（创建版本号）
    db_roll_ptr:7字节，回滚指针（删除版本号）

对于`InnoDb`中在两个并发的事物中，每个事务只能查询到创建版本号小于等于自己事务id的，删除版本号大于等于自己事务id的。  
  在`insert`操作时，会递增一个`db_trx_id`值，因为原则上是只能查询到创建版本号小于等于自己事务id的，因此会在其他事务开启后未提交之前，是查询不到当前新增的数据。  
  在`delete`操作时，当前事务id会递增到`db_roll_ptr`字段上，因为原则上是查删除版本号大于等于自己事务id的，因此当在某个事务删除记录后，以前开启但未关闭的事务，仍旧会查询到在其他事务已经删除的数据。  
  在mysql中`update`操作相当于`insert`和`delete`两个操作。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvaGFxaXlp_size_16_color_FFFFFF_t_70_pic_center]: https://img-blog.csdnimg.cn/20200515082644870.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvaGFxaXlp,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvaGFxaXlp_size_16_color_FFFFFF_t_70_pic_center 1]: https://img-blog.csdnimg.cn/20200515083438606.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvaGFxaXlp,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvaGFxaXlp_size_16_color_FFFFFF_t_70_pic_center 2]: https://img-blog.csdnimg.cn/20200515084830194.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvaGFxaXlp,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvaGFxaXlp_size_16_color_FFFFFF_t_70_pic_center 3]: https://img-blog.csdnimg.cn/20200515124513251.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvaGFxaXlp,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvaGFxaXlp_size_16_color_FFFFFF_t_70_pic_center 4]: https://img-blog.csdnimg.cn/20200521081749635.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvaGFxaXlp,size_16,color_FFFFFF,t_70#pic_center