MySQL事务与MVVC

拼搏现实的明天。 2023-09-30 13:51 18阅读 0赞

### **一、ACID特性** ###

> 数据库管理系统中\*\*事务(transaction)\*\*的四个特性(分析时根据首字母缩写依次解释)：**原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)**
> 
> 所谓事务，它是一个**操作序列，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位**。(执行单个逻辑功能的一组指令或操作称为事务)

#### **1. 原子性** ####

> 原子性是指事务是一个**不可再分割的工作单元**，事务中的操作要么都发生，要么都不发生。
> 
> 可采用“**A向B转账**”这个例子来说明解释
> 
> 在DBMS中，默认情况下**一条SQL就是一个单独事务**，事务是**自动提交**的。只有显式的使用**start transaction**开启一个事务，才能将一个代码块放在事务中执行。

#### **2. 一致性** ####

> 一致性是指在**事务开始之前和事务结束以后**，**数据库的完整性约束没有被破坏**。这是说数据库事务不能破坏**关系数据的完整性**以及**业务逻辑上的一致性**。
> 
> 如A给B转账，不论转账的事务操作是否成功，其两者的存款总额不变(这是业务逻辑的一致性，至于数据库关系约束的完整性就更好理解了)。
> 
> 保障机制(也从两方面着手)：**数据库层面**会在一个事务执行之前和之后，数据会符合你设置的**约束**(**唯一约束，外键约束,check约束**等)和触发器设置；此外，数据库的内部数据结构(如 B 树索引或双向链表)都必须是正确的。业务的一致性一般由开发人员进行保证，亦可转移至数据库层面。

#### **3. 隔离性** ####

> **多个事务并发访问时，事务之间是隔离的**，一个事务不应该影响其它事务运行效果。
> 
> 在并发环境中，当**不同的事务同时操纵相同的数据**时，每个事务都有**各自的完整数据空间**。由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时，数据所处的状态要么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态，**事务不会查看到中间状态的数据**。
> 
> 事务最复杂问题都是由事务隔离性引起的。完全的隔离性是不现实的，完全的隔离性要求数据库同一时间只执行一条事务，这样会严重影响性能。
> 
> 关于隔离性中的事务隔离等级(事务之间影响)，参见相应博文

#### **4. 持久性** ####

> 这是最好理解的一个特性：持久性，意味着在事务完成以后，**该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。**(完成的事务是**系统永久的部分**，对系统的影响是永久性的，该修改即使出现致命的系统故障也将一直保持)
> 
> **write ahead logging**：SQL Server中使用了WAL(Write-Ahead Logging)技术来保证事务日志的ACID特性，在数据写入到数据库之前，先写入到日志，再将日志记录变更到存储器中。

### **二、事务的4种隔离级别** ###

数据库事务的隔离级别有4种，由低到高分别为Read uncommitted 、Read committed 、Repeatable read 、Serializable 。而且，在事务的并发操作中可能会出现脏读，不可重复读，幻读。下面通过事例一一阐述它们的概念与联系。

**Read uncommitted**

读未提交，顾名思义，就是一个事务可以读取另一个未提交事务的数据。

事例：老板要给程序员发工资，程序员的工资是3.6万/月。但是发工资时老板不小心按错了数字，按成3.9万/月，该钱已经打到程序员的户口，但是事务还没有提交，就在这时，程序员去查看自己这个月的工资，发现比往常多了3千元，以为涨工资了非常高兴。但是老板及时发现了不对，马上回滚差点就提交了的事务，将数字改成3.6万再提交。

分析：实际程序员这个月的工资还是3.6万，但是程序员看到的是3.9万。他看到的是老板还没提交事务时的数据。这就是脏读。

那怎么解决脏读呢？Read committed！读提交，能解决脏读问题。

**Read committed**

读提交，顾名思义，就是一个事务要等另一个事务提交后才能读取数据。

事例：程序员拿着信用卡去享受生活(卡里当然是只有3.6万)，当他埋单时(程序员事务开启)，收费系统事先检测到他的卡里有3.6万，就在这个时候！！程序员的妻子要把钱全部转出充当家用，并提交。当收费系统准备扣款时，再检测卡里的金额，发现已经没钱了(第二次检测金额当然要等待妻子转出金额事务提交完)。程序员就会很郁闷，明明卡里是有钱的…

分析：这就是读提交，若有事务对数据进行更新(UPDATE)操作时，读操作事务要等待这个更新操作事务提交后才能读取数据，可以解决脏读问题。但在这个事例中，出现了一个事务范围内两个相同的查询却返回了不同数据，这就是不可重复读。

那怎么解决可能的不可重复读问题？Repeatable read ！

**Repeatable read**

重复读，就是在开始读取数据(事务开启)时，不再允许修改操作

事例：程序员拿着信用卡去享受生活(卡里当然是只有3.6万)，当他埋单时(事务开启，不允许其他事务的UPDATE修改操作)，收费系统事先检测到他的卡里有3.6万。这个时候他的妻子不能转出金额了。接下来收费系统就可以扣款了。

分析：重复读可以解决不可重复读问题。写到这里，应该明白的一点就是，不可重复读对应的是修改，即UPDATE操作。但是可能还会有幻读问题。因为幻读问题对应的是插入INSERT操作，而不是UPDATE操作。

**什么时候会出现幻读？**

事例：程序员某一天去消费，花了2千元，然后他的妻子去查看他今天的消费记录(全表扫描FTS，妻子事务开启)，看到确实是花了2千元，就在这个时候，程序员花了1万买了一部电脑，即新增INSERT了一条消费记录，并提交。当妻子打印程序员的消费记录清单时(妻子事务提交)，发现花了1.2万元，似乎出现了幻觉，这就是幻读。

那怎么解决幻读问题？Serializable！

**Serializable 序列化**

Serializable 是最高的事务隔离级别，在该级别下，事务串行化顺序执行，可以避免脏读、不可重复读与幻读。但是这种事务隔离级别效率低下，比较耗数据库性能，一般不使用。

值得一提的是：大多数数据库默认的事务隔离级别是Read committed，比如Sql Server , Oracle。Mysql的默认隔离级别是Repeatable read。

### **三、MYSQL MVCC 实现机制** ###

#### **3.1 MVVC简介** ####

**什么是MVCC**

MVCC是一种多版本并发控制机制。

**MVCC是为了解决什么问题**

*  大多数的MYSQL事务型存储引擎,如,InnoDB，Falcon以及PBXT都不使用一种简单的行锁机制.事实上,他们都和MVCC–多版本并发控制来一起使用.
 *  大家都应该知道,锁机制可以控制并发操作,但是其系统开销较大,而MVCC可以在大多数情况下代替行级锁,使用MVCC,能降低其系统开销.

**MVCC实现**

MVCC是通过保存数据在某个时间点的快照来实现的. 不同存储引擎的MVCC. 不同存储引擎的MVCC实现是不同的,典型的有乐观并发控制和悲观并发控制.

#### **3.2 MVCC 具体实现分析** ####

下面,我们通过InnoDB的MVCC实现来分析MVCC使怎样进行并发控制的. InnoDB的MVCC,是通过在每行记录后面保存两个隐藏的列来实现的,这两个列，分别保存了这个行的创建时间，一个保存的是行的删除时间。这里存储的并不是实际的时间值,而是系统版本号(可以理解为事务的ID)，每开始一个新的事务，系统版本号就会自动递增，事务开始时刻的系统版本号会作为事务的ID.下面看一下在REPEATABLE READ隔离级别下,MVCC具体是如何操作的.

**简单的小例子**

create table yang( id int primary key auto\_increment, name varchar(20));**假如系统的版本号从1开始**

**INSERT**

InnoDB为新插入的每一行保存当前系统版本号作为版本号. 第一个事务ID为1；

start transaction;
    insert into yang values(NULL,'yang') ;
    insert into yang values(NULL,'long');
    insert into yang values(NULL,'fei');
    commit;

对应在数据中的表如下(后面两列是隐藏列,我们通过查询语句并看不到)

<table> 
 <thead> 
  <tr> 
   <th align="left">id</th> 
   <th align="left">name</th> 
   <th align="left">创建时间(事务ID)</th> 
   <th align="left">删除时间(事务ID)</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">1</td> 
   <td align="left">yang</td> 
   <td align="left">1</td> 
   <td align="left">undefined</td> 
  </tr> 
  <tr> 
   <td align="left">2</td> 
   <td align="left">long</td> 
   <td align="left">1</td> 
   <td align="left">undefined</td> 
  </tr> 
  <tr> 
   <td align="left">3</td> 
   <td align="left">fei</td> 
   <td align="left">1</td> 
   <td align="left">undefined</td> 
  </tr> 
 </tbody> 
</table>

**SELECT**

InnoDB会根据以下两个条件检查每行记录: a.InnoDB只会查找版本早于当前事务版本的数据行(也就是,行的系统版本号小于或等于事务的系统版本号)，这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的. b.行的删除版本要么未定义,要么大于当前事务版本号,这可以确保事务读取到的行，在事务开始之前未被删除. 只有a,b同时满足的记录，才能返回作为查询结果.

**DELETE**

InnoDB会为删除的每一行保存当前系统的版本号(事务的ID)作为删除标识. 看下面的具体例子分析: 第二个事务,ID为2;

start transaction;
    select * from yang;  //(1)
    select * from yang;  //(2)
    commit;

**假设1**

假设在执行这个事务ID为2的过程中,刚执行到(1),这时,有另一个事务ID为3往这个表里插入了一条数据; 第三个事务ID为3;

start transaction;
    insert into yang values(NULL,'tian');
    commit;

这时表中的数据如下:

然后接着执行事务2中的(2),由于id=4的数据的创建时间(事务ID为3),执行当前事务的ID为2,而InnoDB只会查找事务ID小于等于当前事务ID的数据行,所以id=4的数据行并不会在执行事务2中的(2)被检索出来,在事务2中的两条select 语句检索出来的数据都只会下表:

**假设2**

假设在执行这个事务ID为2的过程中,刚执行到(1),假设事务执行完事务3后，接着又执行了事务4; 第四个事务:

start   transaction;  
    delete from yang where id=1;
    commit;

此时数据库中的表如下:

<table> 
 <thead> 
  <tr> 
   <th align="left">id</th> 
   <th align="left">name</th> 
   <th align="left">创建时间(事务ID)</th> 
   <th align="left">删除时间(事务ID)</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">1</td> 
   <td align="left">yang</td> 
   <td align="left">1</td> 
   <td align="left">4</td> 
  </tr> 
  <tr> 
   <td align="left">2</td> 
   <td align="left">long</td> 
   <td align="left">1</td> 
   <td align="left">undefined</td> 
  </tr> 
  <tr> 
   <td align="left">3</td> 
   <td align="left">fei</td> 
   <td align="left">1</td> 
   <td align="left">undefined</td> 
  </tr> 
  <tr> 
   <td align="left">4</td> 
   <td align="left">tian</td> 
   <td align="left">3</td> 
   <td align="left">undefined</td> 
  </tr> 
 </tbody> 
</table>

接着执行事务ID为2的事务(2),根据SELECT 检索条件可以知道,它会检索创建时间(创建事务的ID)小于当前事务ID的行和删除时间(删除事务的ID)大于当前事务的行,而id=4的行上面已经说过,而id=1的行由于删除时间(删除事务的ID)大于当前事务的ID,所以事务2的(2)select \* from yang也会把id=1的数据检索出来.所以,事务2中的两条select 语句检索出来的数据都如下:

<table> 
 <thead> 
  <tr> 
   <th align="left">id</th> 
   <th align="left">name</th> 
   <th align="left">创建时间(事务ID)</th> 
   <th align="left">删除时间(事务ID)</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">1</td> 
   <td align="left">yang</td> 
   <td align="left">1</td> 
   <td align="left">4</td> 
  </tr> 
  <tr> 
   <td align="left">2</td> 
   <td align="left">long</td> 
   <td align="left">1</td> 
   <td align="left">undefined</td> 
  </tr> 
  <tr> 
   <td align="left">3</td> 
   <td align="left">fei</td> 
   <td align="left">1</td> 
   <td align="left">undefined</td> 
  </tr> 
 </tbody> 
</table>

**UPDATE**

InnoDB执行UPDATE，实际上是新插入了一行记录，并保存其创建时间为当前事务的ID，同时保存当前事务ID到要UPDATE的行的删除时间.

**假设3**

假设在执行完事务2的(1)后又执行,其它用户执行了事务3,4,这时，又有一个用户对这张表执行了UPDATE操作: 第5个事务:

start  transaction;
    update yang set name='Long' where id=2;
    commit;

根据update的更新原则:会生成新的一行,并在原来要修改的列的删除时间列上添加本事务ID,得到表如下:

<table> 
 <thead> 
  <tr> 
   <th align="left">id</th> 
   <th align="left">name</th> 
   <th align="left">创建时间(事务ID)</th> 
   <th align="left">删除时间(事务ID)</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">1</td> 
   <td align="left">yang</td> 
   <td align="left">1</td> 
   <td align="left">4</td> 
  </tr> 
  <tr> 
   <td align="left">2</td> 
   <td align="left">long</td> 
   <td align="left">1</td> 
   <td align="left">5</td> 
  </tr> 
  <tr> 
   <td align="left">3</td> 
   <td align="left">fei</td> 
   <td align="left">1</td> 
   <td align="left">undefined</td> 
  </tr> 
  <tr> 
   <td align="left">4</td> 
   <td align="left">tian</td> 
   <td align="left">3</td> 
   <td align="left">undefined</td> 
  </tr> 
  <tr> 
   <td align="left">2</td> 
   <td align="left">Long</td> 
   <td align="left">5</td> 
   <td align="left">undefined</td> 
  </tr> 
 </tbody> 
</table>

继续执行事务2的(2),根据select 语句的检索条件,得到下表:

还是和事务2中(1)select 得到相同的结果.