MySQL：事务知识点盘点

你的名字 2023-09-24 13:06 51阅读 0赞

> 本篇内容包括：MySQL 事务概念、MySQL 事务隔离级别以及MySQL 事务隔离的实现

## 一、MySQL 事务概念 ##

一般来说， MySQL 事务都是指在 InnoDB 引擎下，MyISAM 引擎是不支持事务的。

数据库事务指的是一组数据操作，事务内的操作要么就是全部成功，要么就是全部失败，什么都不做，其实不是没做，是可能做了一部分但是只要有一步失败，就要回滚所有操作，有点一不做二不休的意思。

假设一个网购付款的操作，用户付款后要涉及到订单状态更新、扣库存以及其他一系列动作，这就是一个事务，如果一切正常那就相安无事，一旦中间有某个环节异常，那整个事务就要回滚，总不能更新了订单状态但是不扣库存吧，这问题就大了。

事务具有原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）四个特性，简称 ACID，缺一不可。

###### 1、ACID 简介 ######

在 MySQL中事务的四大特性主要包含：原子性（Atomicity）、一致性（Consistent）、隔离性（Isalotion）、持久性(Durable)，简称为 ACID。

*  原子性：是指事务的原子性操作，对数据的修改要么全部执行成功，要么全部失败，实现事务的原子性，是基于日志的Redo/Undo机制
 *  一致性：是指执行事务前后的状态要一致，可以理解为数据一致性。
 *  隔离性：是指事务之间相互隔离，不受影响，事务中间状态的数据不会被其他并发事务查看，这个与事务设置的隔离级别有密切的关系。
 *  持久性：是指在一个事务提交后，这个事务的状态会被持久化到数据库中，也就是事务提交，对数据的新增、更新将会持久化到数据库中。

原子性、隔离性、持久性都是为了保障一致性而存在的，一致性也是最终的目的

###### 2、ACID 原理 ######

Redo/Undo 机制将所有对数据的更新操作都写到日志中

*  Redo log：用来记录某数据块被修改后的值，可以用来恢复未写入 data file 的已成功事务更新的数据，保证了持久性；
 *  Undo log：用来记录数据更新前的值，保证数据更新失败能够回滚，保证了原子性。

假如数据库在执行的过程中，不小心崩了，可以通过该日志的方式，回滚之前已经执行成功的操作，实现事务的一致性：

假如某个时刻数据库崩溃，在崩溃之前有事务A和事务B在执行，事务A已经提交，而事务B还未提交。当数据库重启进行 crash-recovery 时，就会通过 Redo log 将已经提交事务的更改写到数据文件，而还没有提交的就通过 Undo log 进行r oll back。

###### 3、MySQL 中执行事务 ######

事务的执行过程如下，以 begin 或者 start transaction 开始，然后执行一系列操作，最后要执行 commit 操作，事务才算结束。当然，如果进行回滚操作，事务也会结束。

![img][]

需要注意的是，begin 命令并不代表事务的开始，事务开始于 begin 命令之后的第一条语句执行的时候。

--------------------

## 二、MySQL 事务隔离级别 ##

###### 1、并发情况下事务引发的问题 ######

一般情况下，多单元操作并发执行，会出现以下几个问题：

*  脏读：脏读指的是读到了其他事务未提交的数据，未提交意味着这些数据可能会回滚，也就是可能最终不会存到数据库中，也就是不存在的数据。读到了并一定最终存在的数据，这就是脏读。（破坏了隔离性）
 *  不可重复读：不可重复读指的是在同一事务内，不同的时刻读到的同一批数据可能是不一样的，可能会受到其他事务的影响，比如其他事务改了这批数据并提交了。通常针对数据更新（UPDATE）操作。（破坏了一致性，update & delete）
 *  幻读：幻读是针对数据插入（INSERT）操作来说的。假设事务 A 对某些行的内容作了更改，但是还未提交，此时事务 B 插入了与事务 A 更改前的记录相同的记录行，并且在事务 A 提交之前先提交了，而这时，在事务 A 中查询，会发现好像刚刚的更改对于某些数据未起作用，但其实是事务B刚插入进来的，让用户感觉很魔幻，感觉出现了幻觉，这就叫幻读。（破坏了一致性，Insert）

###### 2、解决（指定标准） ######

为了权衡隔离和并发的矛盾，ISO定义了四个事务隔离级别，每个级别的隔离程度不同，允许出现的副作用也不同

SQL 标准的事务隔离级别包括：

1.  读未提交（READ UNCOMMITTED）
2.  读已提交 （READ COMMITTED）
3.  可重复读 （REPEATABLE READ）
4.  串行化 （SERIALIZABLE）

<table> 
 <thead> 
  <tr> 
   <th align="center">事务隔离级别</th> 
   <th align="center">脏读</th> 
   <th align="center">不可重复读</th> 
   <th align="center">幻读</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="center">读未提交</td> 
   <td align="center">会</td> 
   <td align="center">会</td> 
   <td align="center">会</td> 
  </tr> 
  <tr> 
   <td align="center">读已提交</td> 
   <td align="center">-</td> 
   <td align="center">会</td> 
   <td align="center">会</td> 
  </tr> 
  <tr> 
   <td align="center">可重复读</td> 
   <td align="center">-</td> 
   <td align="center">-</td> 
   <td align="center">会</td> 
  </tr> 
  <tr> 
   <td align="center">串行化</td> 
   <td align="center">-</td> 
   <td align="center">-</td> 
   <td align="center">-</td> 
  </tr> 
 </tbody> 
</table>

###### 3、读未提交 ######

MySQL 事务隔离其实是依靠锁来实现的，加锁自然会带来性能的损失。而读未提交隔离级别是不加锁的，所以它的性能是最好的，没有加锁、解锁带来的性能开销。但有利就有弊，这基本上就相当于裸奔啊，所以它连脏读的问题都没办法解决。

任何事务对数据的修改都会第一时间暴露给其他事务，即使事务还没有提交。

###### 4、读已提交 ######

既然读未提交没办法解决脏数据问题，那么就有了读提交。读提交就是一个事务只能读到其他事务已经提交过的数据，也就是其他事务调用 commit 命令之后的数据。那脏数据问题迎刃而解了。

读提交事务隔离级别是大多数流行数据库的默认事务隔离界别，比如 Oracle，但是不是 MySQL 的默认隔离界别。

###### 5、可重复读 ######

可重复是对比不可重复而言的，上面说不可重复读是指同一事物不同时刻读到的数据值可能不一致。而可重复读是指，事务不会读到其他事务对已有数据的修改，及时其他事务已提交，也就是说，事务开始时读到的已有数据是什么，在事务提交前的任意时刻，这些数据的值都是一样的。但是，对于其他事务新插入的数据是可以读到的，这也就引发了幻读问题。

要说明的是，当你在 MySQL 中测试幻读的时候，并不会出现上图的结果，幻读并没有发生，MySQL 的可重复读隔离级别其实解决了幻读问题

###### 6、串行化 ######

串行化是4种事务隔离级别中隔离效果最好的，解决了脏读、可重复读、幻读的问题，但是效果最差，它将事务的执行变为顺序执行，与其他三个隔离级别相比，它就相当于单线程，后一个事务的执行必须等待前一个事务结束。

--------------------

## 三、MySQL 事务隔离的实现 ##

首先说读未提交，它是性能最好，也可以说它是最野蛮的方式，因为它压根儿就不加锁，所以根本谈不上什么隔离效果，可以理解为没有隔离。

再来说串行化。读的时候加共享锁，也就是其他事务可以并发读，但是不能写。写的时候加排它锁，其他事务不能并发写也不能并发读。

最后说读提交和可重复读。这两种隔离级别是比较复杂的，既要允许一定的并发，又想要兼顾的解决问题。

###### 1、实现可重复读 ######

为了解决不可重复读，或者为了实现可重复读，MySQL 采用了 MVVC (多版本并发控制) 的方式。

我们在数据库表中看到的一行记录可能实际上有多个版本，每个版本的记录除了有数据本身外，还要有一个表示版本的字段，记为 row trx\_id，而这个字段就是使其产生的事务的 id，事务 ID 记为 transaction id，它在事务开始的时候向事务系统申请，按时间先后顺序递增。

![img][img 1]

按照上面这张图理解，一行记录现在有 3 个版本，每一个版本都记录这使其产生的事务 ID，比如事务A的transaction id 是100，那么版本1的row trx\_id 就是 100，同理版本2和版本3。

在上面介绍读提交和可重复读的时候都提到了一个词，叫做快照，学名叫做一致性视图，这也是可重复读和不可重复读的关键，可重复读是在事务开始的时候生成一个当前事务全局性的快照，而读提交则是每次执行语句的时候都重新生成一次快照。

对于一个快照来说，它能够读到那些版本数据，要遵循以下规则：

1.  当前事务内的更新，可以读到；
2.  版本未提交，不能读到；
3.  版本已提交，但是却在快照创建后提交的，不能读到；
4.  版本已提交，且是在快照创建前提交的，可以读到；

利用上面的规则，再返回去套用到读提交和可重复读的那两张图上就很清晰了。还是要强调，两者主要的区别就是在快照的创建上，可重复读仅在事务开始是创建一次，而读提交每次执行语句的时候都要重新创建一次。

###### 2、并发写问题 ######

存在这的情况，两个事务，对同一条数据做修改。最后结果应该是哪个事务的结果呢，肯定要是时间靠后的那个对不对。并且更新之前要先读数据，这里所说的读和上面说到的读不一样，更新之前的读叫做“当前读”，总是当前版本的数据，也就是多版本中最新一次提交的那版。

假设事务A执行 update 操作， update 的时候要对所修改的行加行锁，这个行锁会在提交之后才释放。而在事务A提交之前，事务B也想 update 这行数据，于是申请行锁，但是由于已经被事务A占有，事务B是申请不到的，此时，事务B就会一直处于等待状态，直到事务A提交，事务B才能继续执行，如果事务A的时间太长，那么事务B很有可能出现超时异常。如下图所示。

![img][img 2]

加锁的过程要分有索引和无索引两种情况，比如下面这条语句

update user set age=11 where id = 1

id 是这张表的主键，是有索引的情况，那么 MySQL 直接就在索引数中找到了这行数据，然后干净利落的加上行锁就可以了。

而下面这条语句

update user set age=11 where age=10

表中并没有为 age 字段设置索引，所以， MySQL 无法直接定位到这行数据。那怎么办呢，当然也不是加表锁了。MySQL 会为这张表中所有行加行锁，没错，是所有行。但是呢，在加上行锁后，MySQL 会进行一遍过滤，发现不满足的行就释放锁，最终只留下符合条件的行。虽然最终只为符合条件的行加了锁，但是这一锁一释放的过程对性能也是影响极大的。所以，如果是大表的话，建议合理设计索引，如果真的出现这种情况，那很难保证并发度。

###### 3、解决幻读 ######

上面介绍可重复读的时候，那张图里标示着出现幻读的地方实际上在 MySQL 中并不会出现，MySQL 已经在可重复读隔离级别下解决了幻读的问题。

前面刚说了并发写问题的解决方式就是行锁，而解决幻读用的也是锁，叫做间隙锁，MySQL 把行锁和间隙锁合并在一起，解决了并发写和幻读的问题，这个锁叫做 Next-Key 锁。

假设现在表中有两条记录，并且 age 字段已经添加了索引，两条记录 age 的值分别为 10 和 30。

![img][img 3]

此时，在数据库中会为索引维护一套B+树，用来快速定位行记录。B+索引树是有序的，所以会把这张表的索引分割成几个区间。

![img][img 4]

如图所示，分成了3 个区间，(负无穷,10\]、(10,30\]、(30,正无穷\]，在这3个区间是可以加间隙锁的。

之后，我用下面的两个事务演示一下加锁过程。

![img][img 5]

在事务A提交之前，事务B的插入操作只能等待，这就是间隙锁起得作用。当事务A执行`update user set name='风筝2号’ where age = 10;` 的时候，由于条件 where age = 10 ，数据库不仅在 age =10 的行上添加了行锁，而且在这条记录的两边，也就是(负无穷,10\]、(10,30\]这两个区间加了间隙锁，从而导致事务B插入操作无法完成，只能等待事务A提交。不仅插入 age = 10 的记录需要等待事务A提交，age<10、10<age<30 的记录页无法完成，而大于等于 30 的记录则不受影响，这足以解决幻读问题了。

这是有索引的情况，如果 age 不是索引列，那么数据库会为整个表加上间隙锁。所以，如果是没有索引的话，不管 age 是否大于等于30，都要等待事务 A 提交才可以成功插入。

[img]: https://pic2.zhimg.com/v2-878a1a7f09b0135c7f72faa4c9670aed_b.jpg
[img 1]: https://pic1.zhimg.com/v2-114dd6691636883a92e7c1060210a014_b.jpg
[img 2]: https://img-blog.csdnimg.cn/img_convert/637dff98f7061d4069b198d6e9c68c23.jpeg
[img 3]: https://img-blog.csdnimg.cn/img_convert/ea2aeee9270990733b3109fdb0c013c1.png
[img 4]: https://img-blog.csdnimg.cn/img_convert/cb8ce8795087e589061050bdba044abd.jpeg
[img 5]: https://img-blog.csdnimg.cn/img_convert/558bcf7fddbecb88fd7231d8f2cda481.jpeg