MySQL 事务最全解析

╰半夏微凉° 2023-10-18 23:41 161阅读 0赞

#### 文章目录 ####

*  1. 事务的属性
 *   *   *  1.1 事务的实现原理
         *   *   *  1.1.1. redo log
                 *  1.1.2. undo log
         *  1.2 事务的提交流程
 *  2. 数据库隔离性
 *   *   *  2.1. 数据库隔离级别
         *   *  2.1.1 READ UNCOMMITTED(读写均不使用锁, 未提交读, 会读取未提交内容)
             *  2.1.2 READ COMMITTED(使用写锁, 提交读, 会读取其他事务已提交内容)
             *  2.1.3 Repeatable Read(使用读锁和写锁, 可重复读)
             *   *  MVCC是如何工作的
             *  2.1.4 Serializable(可串行化)
         *  2.2. 并发事务带来的问题
         *   *   *  幻读和不可重复读的区别
 *  3. 数据库锁
 *   *   *  3.1. 锁的粒度分类
         *   *   *  3.1.1. 行锁:InnoDB 存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁.
                 *  3.1.2. 表锁: MyISAM 和 MEMORY 存储引擎采用的是表级锁（table-level locking）.
                 *  3.1.3. 页面锁:BDB 存储引擎采用的是页面锁（page-level locking），但也支持表级锁.
         *  3.2. 锁的功能分类
         *   *   *  3.2.1. 读锁(共享锁, Share Lock):
                 *  3.2.2. 写锁(排他锁, Exclusive Lock):
                 *  3.2.3. 更新锁(U锁): 用于从读锁向写锁的升级
         *  3.3. 其他的锁概念
         *   *   *  3.3.1. InnoDB 间隙锁
                 *  3.3.2. InnoDB 意向锁（Intention Locks）
         *  3.4. 死锁
         *  3.5. InnoDB 行锁优化建议
 *  4. Spring 中事务的传播

## 1. 事务的属性 ##

事务就是一组原子性的 sql 操作, mysql 引擎要么会全部执行这一组 sql 语句，要么全部都不执行  
数据库事务必须具有以下四个特性(ACID):

1.  `Atomicity（原子性）`：一个事务必须被视为一个不可分割的最小工作单元，整个事务中的所有操作要么全部提交成功，要么全部失败回滚，对于一个事务来说，不可能只执行其中的一部分操作
2.  `Consistency（一致性）`：在事务开始之前和事务结束以后，数据库的完整性没有被破坏
3.  `Isolation（隔离性）`：数据库允许多个并发事务同时对其数据进行读写和修改的能力,但是多个事务并发访问时，事务之间是隔离的，一个事务不应该影响其它事务的运行效果
4.  `Durability（持久性）`：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失

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

#### 1.1 事务的实现原理 ####

事务的隔离性是通过锁实现，而事务的原子性、一致性和持久性则是通过事务日志实现.说到事务日志，就必须要提及`redo`和`undo`。**redo log 和 undo log 共同保障了事务的持久性、一致性和原子性**

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

###### 1.1.1. redo log ######

*  InnoDB 的存储引擎中，事务日志通过重做(redo)日志和 InnoDB 存储引擎的日志缓冲(InnoDB Log Buffer)实现。事务开启时，事务中的操作，都会先写入存储引擎的日志缓冲中，在事务提交之前，这些缓冲的日志都需要提前刷新到磁盘上持久化，这就是 DBA 口中的`“日志先行”(Write-Ahead Logging)`。当事务提交之后，在Buffer Pool中映射的数据文件才会慢慢刷新到磁盘.此时如果数据库崩溃或者宕机，那么当系统重启进行恢复时，就可以根据redo log中记录的日志，把数据库恢复到崩溃前的一个状态。未完成的事务，可以继续提交，也可以选择回滚，这基于恢复的策略而定
 *  在系统启动的时候，就已经为redo log分配了一块连续的存储空间,以顺序追加的方式记录Redo Log,通过顺序IO来改善性能.所有的事务共享redo log的存储空间，它们的Redo Log按语句的执行顺序，依次交替的记录在一起

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

###### 1.1.2. undo log ######

*  undo log 主要为事务的回滚及 MVCC 服务。在事务执行的过程中，除了记录 redo log，还会记录一定量的 undo log。`undo log`是逻辑日志，它记录的是和原 sql 相反的 sql , 比如 insert 对应 delete, update 对应另外一个update。通过这种方式，`undo log`记录了数据在每个更新操作前的状态，如果事务执行过程中需要回滚，就可以根据 undo log 进行回滚操作。单个事务的回滚，只会回滚当前事务做的操作，并不会影响到其他的事务做的操作

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

#### 1.2 事务的提交流程 ####

在一次更改数据的事务提交中，以上几种 log 的刷盘流程如下，总结起来就是： `开启事务-> 找目标记录-> 生成 undo log 记录旧值-> 修改数据 -> 生成 redo log 并刷盘 -> 提交事务，生成bin log并刷盘 -> 事务完成，redo log 状态为已提交`

> 1.  分配事务ID ，开启事务，获取锁，没有获取到锁则等待
> 2.  执行器先通过存储引擎找到的数据页，如果缓冲池有则直接取出，没有则去主键索引上取出对应的数据页放入缓冲池
> 3.  在数据页内找到记录，取出数据生成 undo log 记录旧值，更改后写入内存
> 4.  生成 redo log 到内存，redo log 状态为 prepare
> 5.  准备提交事务，将 redo log 和 undo log 写入文件并调用 fsync
> 6.  提交事务，server 层生成 bin log 并写入文件调用 fsync
> 7.  事务完成，将 redo log 的状态改为 commited， 释放锁

## 2. 数据库隔离性 ##

数据库允许多个事务并发执行， 因此各个事务之间需要进行隔离，以避免一个事务对其他事务的运行产生影响. SQL 定义了 4个隔离级别，每一种级别都规定了一个事务中所做的修改，哪些在事务间可见，哪些在事务间不可见. 低级别的隔离级一般支持更高的并发处理，并拥有更低的系统开销.  
事务的实现是基于数据库的存储引擎,不同的存储引擎对事务的支持程度不一样,mysql中支持事务的存储引擎有InnoDB和NDB.

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

#### 2.1. 数据库隔离级别 ####

##### 2.1.1 READ UNCOMMITTED(读写均不使用锁, 未提交读, 会读取未提交内容) #####

1.  所有事务都可以看到其他未提交事务的执行结果.
2.  该隔离级别很少实际应用，因为它的性能并不比其他级别好多少.
3.  该级别引发的问题是——脏读(Dirty Read)：读取到了未提交的数据.

##### 2.1.2 READ COMMITTED(使用写锁, 提交读, 会读取其他事务已提交内容) #####

1.  大多数数据库系统的默认隔离级别（但不是MySQL默认的）.
2.  满足了隔离的简单定义：一个事务只能看见已经提交的事务所做的改变.
3.  这种隔离级别出现的问题是——不可重复读(Nonrepeatable Read)：不可重复读意味着在同一个事务中执行完全相同的select语句时可能看到不一样的结果。导致这种情况的原因有：
    
        1.有一个交叉的事务有新的commit，导致了数据的改变;
        2.一个数据库被多个实例操作时,同一事务的其他实例在该实例处理其间可能会有新的commit

##### 2.1.3 Repeatable Read(使用读锁和写锁, 可重复读) #####

1.  MySQL的默认事务隔离级别
2.  确保同一事务的多个实例在并发读取数据时，会看到同样的数据行
3.  该级别可能出现的问题——幻读(Phantom Read)：当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行.
4.  InnoDB 和 Falcon 存储引擎通过多版本并发控制(MVCC，Multiversion Concurrency Control)机制解决快照读（普通 select 语句）幻读问题，InnoDB 还通过间隙锁解决当前读（select … for update，update，delete 等语句）幻读问题

###### MVCC是如何工作的 ######

1.  InnoDB 的 MVCC 是通过在每行记录后面保存两个隐藏的列(其实是三列，第三列是用于事务回滚)来实现.这两个列一个保存了行的创建时间，一个保存行的过期时间（删除时间）。不过存储的并不是真实的时间而是系统版本号（system version number）。每开始一个新的事务，系统版本号都会自动新增，事务开始时刻的系统版本号会作为事务的版本号，用来与undo中保存的行版本信息进行比较，从而确定每个事务自己的历史数据，实现非阻塞的读操作，读时不加锁，读写不冲突
2.  保存这两个版本号使大多数操作都不用加锁, 数据操作更简单，性能很好，并且能保证只会读取到符合要求的行.不足之处是每行记录都需要额外的存储空间，需要做更多的行检查工作和一些额外的维护工作
3.  MVCC只在 `COMMITTED READ`和`REPEATABLE READ`两种隔离级别下工作，在 `COMMITTED READ`隔离级别下一致性非锁定读总是读取被锁定行最新的快照数据，而`REPEATABLE READ`隔离级别则总是读被锁定行事务开始时的版本号快照数据

##### 2.1.4 Serializable(可串行化) #####

1.  这是最高的隔离级别
2.  通过强制事务按顺序执行，使之不可能相互冲突，从而解决幻读问题.它是在每个读的数据行上加上共享锁
3.  这个级别可能导致大量的超时现象和锁竞争,性能表现不佳

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

#### 2.2. 并发事务带来的问题 ####

*  更新丢失：当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问题 －－最后的更新覆盖了由其他事务所做的更新
 *  脏读：一个事务未提交的中间状态的更新数据被其他会话读取到.当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中(commit未执行)，这时另一个会话也访问这个数据，因为这个数据是还没有提交， 那么它读到的这个数据就是脏数据，依据脏数据所做的操作也可能是不正确的
 *  不可重复读：在同一事务中，多次读取同一数据返回的结果有所不同.换句话说就是，后续读取到另一会话事务已提交的更新数据.“可重复读”就是在同一事务中多次读取数据时，能够保证所读数据一样，也就是后续读取不能读到另一会话事务已提交的更新数据
 *  幻读：会话T1事务中执行一次查询，然后会话T2新插入一行记录，这行记录恰好可以满足T1所使用的查询的条件.然后T1又使用相同的查询再次对表进行检索，但是此时却看到了事务T2刚才插入的新行.这个新行就称为“幻象”，因为对T1来说这一行数据就像是"幻觉"

###### 幻读和不可重复读的区别 ######

*  不可重复读的重点是修改：在同一事务中，同样的条件，第一次读的数据和第二次读的数据不一样.（因为中间有其他事务提交了修改）
 *  幻读的重点在于新增或者删除：在同一事务中，同样的条件, 第一次和第二次读出来的记录数不一样.（因为中间有其他事务提交了插入/删除）

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

## 3. 数据库锁 ##

*  总概

数据库锁按照是否加锁一般可以分为两类，一个是悲观锁，一个是乐观锁.

*  `乐观锁`一般是用户自己实现的一种锁机制，假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候才会正式对数据的冲突与否进行检测，如果发现冲突了，则返回用户错误的信息，让用户决定如何去做.乐观锁的实现方式一般包括使用版本号和时间戳.
 *  `悲观锁`就是我们通常说的数据库锁机制，以下都是基于悲观锁.  
    数据库悲观锁按照锁粒度分类有表锁、行锁、页锁.在MyISAM中只用到表锁, 一次性获取SQL 语句所需要的全部锁,不会有死锁的问题，锁的开销很小，但相应的并发能力也很差. Innodb实现了行级锁和表锁，锁的粒度变小了，并发能力变强，但是相应的锁的开销变大，很有可能出现死锁.

表锁和行锁都分为共享锁和排他锁（独占锁），而更新锁是为了解决行锁升级（共享锁升级为独占锁）的死锁问题.InnoDB中表锁和行锁一起用，所以为了提高效率才会有意向锁（意向共享锁和意向排他锁）

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

#### 3.1. 锁的粒度分类 ####

按照锁住的数据数量为粒度依据,可将锁分为:

###### 3.1.1. 行锁:InnoDB 存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁. ######

*  开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高.
 *  最大程度的支持并发，同时也带来了最大的锁开销.
 *  在 InnoDB 中，除单个 SQL 组成的事务外，锁是逐步获得的，这就决定了在 InnoDB 中发生死锁是可能的.
 *  行级锁只在存储引擎层实现，而Mysql服务器层没有实现.行级锁更适合于有大量按索引条件并发更新少量不同数据，同时又有并发查询的应用，如一些在线事务处理（OLTP）系统.

InnoDB行锁是通过给索引上的索引项加锁来实现的，只有真正通过索引条件检索数据，InnoDB才使用行级锁，否则 InnoDB 将使用表锁

###### 3.1.2. 表锁: MyISAM 和 MEMORY 存储引擎采用的是表级锁（table-level locking）. ######

*  开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低.
 *  存储引擎通过总是一次性同时获取所有需要的锁以及总是按相同的顺序获取表锁来避免死锁.
 *  表级锁更适合于以查询为主，并发用户少，只有少量按索引条件更新数据的应用，如Web 应用.

###### 3.1.3. 页面锁:BDB 存储引擎采用的是页面锁（page-level locking），但也支持表级锁. ######

*  开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般.

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

#### 3.2. 锁的功能分类 ####

按照锁的功能目标可将锁分为:

###### 3.2.1. 读锁(共享锁, Share Lock): ######

*  多个事务可封锁同一个共享页.
 *  但任何事务都不能修改该页.
 *  通常是该页被读取完毕，S锁立即被释放.

###### 3.2.2. 写锁(排他锁, Exclusive Lock): ######

*  仅允许一个事务封锁此页.
 *  其他任何事务必须等到X锁被释放才能对该页进行读写访问.
 *  写锁一直到事务结束才能被释放.

###### 3.2.3. 更新锁(U锁): 用于从读锁向写锁的升级 ######

使用共享锁时，修改数据的操作分为两步： 
    1. 首先获得一个共享锁，读取数据， 
    2. 将共享锁升级为排他锁，再执行修改操作.
     
    这样如果有两个或多个事务同时对一个事务申请了共享锁，在修改数据时，这些事务都要将共享锁升级为排他锁.
    这时，这些事务都不会释放共享锁，而是一直等待对方释放，这样就造成了死锁. 
    如果一个数据在修改前直接申请更新锁，在数据修改时再升级为排他锁，就可以避免死锁.

*  用来预定要对此页施加写锁，允许其他事务读，但不允许再施加更新锁或写锁.
 *  当被读取的页要被更新时，则升级为写锁.
 *  更新锁一直到事务结束时才能被释放.

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

#### 3.3. 其他的锁概念 ####

###### 3.3.1. InnoDB 间隙锁 ######

当前读 情况下， 对于键值在条件范围内但并不存在的记录(比如表中只有100行，而条件为 id >10 时还没有插入表中的 id > 100 的记录)，叫做“间隙（GAP)”，InnoDB也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁

> `Gap Lock`: 间隙锁，锁定一个范围但不包含记录本身  
> `Record Lock`: 记录锁，锁定一个记录本身  
> `Next-Key Lock`: Gap Lock + Record Lock，锁定一个范围并且锁定记录本身

`InnoDB 这种加锁机制会阻塞符合条件范围内键值的并发修改（插入、删除）`，往往会造成严重的锁等待，不过可以使用这种方式防止当前读的幻读，以满足相关隔离级别的要求

###### 3.3.2. InnoDB 意向锁（Intention Locks） ######

为了允许行锁和表锁共存，实现多粒度锁机制，InnoDB 还有两种内部使用的意向锁（Intention Locks），这两种意向锁都是表锁:

*  **意向共享锁（IS）**：事务打算给数据行加行共享锁，事务在给一个数据行加共享锁前必须先取得该表的 IS 锁.
 *  **意向排他锁（IX）**：事务打算给数据行加行排他锁，事务在给一个数据行加排他锁前必须先取得该表的 IX 锁.

当一个表中的某一行被加上排他锁后,显然这个表就不能再被加表锁.那么数据库程序如何知道该表不能被加表锁?  
一种方式是逐条的判断该表的每一条记录是否已经有排他锁,另一种方式是直接在表这一层级检查表本身是否有意向锁,不需要逐条判断,显然后者效率高.

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

#### 3.4. 死锁 ####

多数情况下如果一个资源被锁定,它总会在以后某个时间被释放.但当多个进程访问同一数据时,其中每个进程拥有的锁都是其他进程所需的,由此造成每个进程都无法继续下去.简单的说，进程A等待进程B释放他的资源，B又等待A释放他的资源，这样就互相等待就形成死锁

*  **死锁发生的原因**
    
    1.  系统资源不足.
    2.  资源分配不当.
    3.  进程运行推进的顺序不合适.
 *  **死锁发生的条件**
    
    1.  互斥条件:在一段时间内一个资源只能被一个进程使用.
    2.  请求与保持条件:进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对自己已获得的其它资源保持不放.
    3.  不可强占:线程已获得的资源在使用结束之前不可被强行剥夺,只能由自己释放.
    4.  循环等待:若干进程形成一种循环等待资源的关系.
 *  **死锁的处理策略**:
    
    1.  死锁预防：
        
        >  *  打破互斥条件：  
        >     允许进程同时访问资源,（有些资源无法共享，实用价值较低）
        >  *  打破不可强占条件：  
        >     给进程设置优先级，高优先级的可以抢占资源(实现困难，降低系统性能)
        >  *  打破请求与保持条件：  
        >     实行资源预分配策略，即进程在运行前一次性向系统申请它所需要的全部资源(不可预测资源的使用，利用率低，降低并发性)
        >  *  破坏循环等待条件：  
        >     把资源事先分类编号，按号分配，所有进程对资源的请求必须严格按资源序号递增的顺序提出，使进程在申请占用资源时不会形成循环。（限制和编号实现困难，增加系统开销，有些资源暂时不用也需要先申请，增加了进程对资源的占用时间）
    2.  死锁避免
        
        >  *  允许进程动态申请资源，但系统在进行资源分配前，应先计算此次资源分配的安全性。若此次分配不会导致系统进入不安全状态，则将资源分配给进程，否则让进程等待
        >  *  所谓安全状态，是指系统能按某种进程推进顺序，为每个进程分配其所需的资源，直至满足每个进程对资源的最大需求，使每个进程都可以顺序地完成。并非所有的不安全状态都是死锁状态，但当系统进入不安全状态后，便可能进入死锁状态；反之，只要系统处于安全状态，系统便可以避免进入死锁状态。银行家算法是最著名的死锁避免算法
    3.  死锁检测与解除
        
        >  *  不采取任何限制措施来保证系统不进入死锁状态，也就是允许死锁发生，但操作系统建立资源分配表和进程等待表，不断监督进程的路径，判断死锁是否真的发生。一旦死锁发生，则采取专门的措施解除死锁，并以最小代价使得整个系统恢复正常。
        >  *  死锁解除可使用以下方法：  
        >     剥夺资源：从其他进程强制剥夺资源给死锁进程  
        >     撤销进程：直接撤销死锁进程，或撤销代价最小的进程
 *  **案例**:

1.  一个用户A 访问表A(锁住了表A)，然后又访问表B
2.  另一个用户B 访问表B(锁住了表B)，然后企图访问表A
3.  用户A由于用户B已经锁住表B, 必须等待用户B释放表B才能继续, 同样用户B要等用户A释放表A才能继续，这样死锁就产生了.

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

#### 3.5. InnoDB 行锁优化建议 ####

*  尽可能让所有的数据检索都通过索引来完成，从而避免Innodb因为无法通过索引键加锁而升级为表级锁定.
 *  合理设计索引，让 InnoDB 在索引键上面加锁尽可能准确，尽可能的缩小锁定范围，避免造成不必要的锁定而影响其他查询的执行.
 *  尽可能减少基于范围的数据检索过滤条件，避免间隙锁带来的负面影响而锁定了不该锁定的记录.
 *  尽量控制事务的大小，减少锁定的资源量和锁定时间长度.
 *  在业务环境允许的情况下，尽量使用较低级别的事务隔离，以减少MySQL因为实现事务隔离级别所带来的附加成本.

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

## 4. Spring 中事务的传播 ##

事务传播行为用来描述由某一个事务传播行为修饰的方法被嵌套进另一个方法的时候事务如何传播.

<table> 
 <thead> 
  <tr> 
   <th align="left">事务传播行为类型</th> 
   <th align="left">说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">PROPAGATION_REQUIRED</td> 
   <td align="left">如果当前没有事务，就新建一个事务，如果已经存在一个事务中，加入到这个事务中.</td> 
  </tr> 
  <tr> 
   <td align="left">PROPAGATION_SUPPORTS</td> 
   <td align="left">支持当前事务，如果当前没有事务，就以非事务方式执行.</td> 
  </tr> 
  <tr> 
   <td align="left">PROPAGATION_MANDATORY</td> 
   <td align="left">使用当前的事务，如果当前没有事务，就抛出异常.</td> 
  </tr> 
  <tr> 
   <td align="left">PROPAGATION_REQUIRES_NEW</td> 
   <td align="left">新建事务，如果当前存在事务，把当前事务挂起.</td> 
  </tr> 
  <tr> 
   <td align="left">PROPAGATION_NOT_SUPPORTED</td> 
   <td align="left">以非事务方式执行操作，如果当前存在事务，就把当前事务挂起.</td> 
  </tr> 
  <tr> 
   <td align="left">PROPAGATION_NEVER</td> 
   <td align="left">以非事务方式执行，如果当前存在事务，则抛出异常.</td> 
  </tr> 
  <tr> 
   <td align="left">PROPAGATION_NESTED</td> 
   <td align="left">如果当前存在事务，则在嵌套事务内执行.如果当前没有事务，则执行与PROPAGATION_REQUIRED类似的操作.</td> 
  </tr> 
 </tbody> 
</table>