【MySQL】事务与锁（一）：详解数据库事务及并发时可能出现的问题

心已赠人 2022-11-21 11:22 221阅读 0赞

在项目里面，什么地方会开启事务，或者配置了事务？无论是在方法上加注解，还是配置切面。

<tx:adviceid="txAdvice"transaction-manager="transactionManager"> 
        <tx:attributes>
            <tx:methodname="save*" rollback-for="Throwable"/> 
            <tx:methodname="add*" rollback-for="Throwable"/>
            <tx:methodname="send*" rollback-for="Throwable"/> 
            <tx:methodname="insert*" rollback-for="Throwable"/>
        </tx:attributes> 
    </tx:advice>

比如下单，会操作订单表，资金表，物流表等等，这个时候我们需要让这些操作都在一个事务里面完成。当一个业务流程涉及多个表的操作的时候，我们希望它们要么是全部成功的，要么都不成功，这个时候我们会启用事务。

在金融的系统里面事务配置是很常见的，比如行内转账的这种操作，如果我们把它简单地理解为一个账户的余额增加，另一个账户的余额减少的情况（当然实际上要比这复杂），那么这两个动作一定是同时成功或者同时失败的，否则就会造成银行的会计科目不平衡。

## 1.什么是事务？ ##

> 维基百科的定义：事务是数据库管理系统（DBMS）执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。

可以通俗理解为：就是把多件事情当做一件事情来处理，好比大家同在一条船上，要活一起活，要完一起完 。

这里面有两个关键点：

1.  它是数据库最小的工作单元，是不可以再分的（所有的 CUD 操作都是事务，即使单条 SQL）
2.  它可能包含了一个或者一系列的DML语句，包括 insert delete update。（单条DDL（create drop）和 DCL（grant revoke）也会有事务）

**所以，数据库中哪些存储引擎支持事务？**

在 [查询sql的执行过程及MySQL架构分析][sql_MySQL] 里面我们说到了，InnoDB支持事务，这个也是它成为默认的存储引擎的一个重要原因：[https://dev.mysql.com/doc/refman/5.7/en/storage-engines.html][https_dev.mysql.com_doc_refman_5.7_en_storage-engines.html]，另一个是NDB。

## 2.事务的四大特性 ##

事务的四大特性：ACID。

### 2.1 原子性（Atomicity） ###

原子性也就是我们刚才说的不可再分，也就意味着我们对数据库的一系列的操作，要么都是成功，要么都是失败，不可能出现部分成功或者部分失败的情况。以转账的场景为例，一个账户的余额减少，对应一个账户的增加，这两个一定是同时成功或者同时失败的。

全部成功比较简单，问题是如果前面一个操作已经成功了，后面的操作失败了，怎么让它全部失败呢？这个时候我们必须要回滚。

原子性，在InnoDB里面是通过undo log来实现的，它记录了数据修改之前的值（逻辑日志），一旦发生异常，就可以用undo log 来实现回滚操作。

### 2.2 一致性（Consistent） ###

一致性指的是数据库的完整性约束没有被破坏，事务执行的前后都是合法的数据状态。比如主键必须是唯一的，字段长度符合要求。

除了数据库自身的完整性约束，还有一个是用户自定义的完整性。比如说转账的这个场景，A账户余额减少1000，B账户余额只增加了500，这个时候因为两个操作都成功了，按照我们对原子性的定义，它是满足原子性的， 但是它没有满足一致性，因为它导致了会计科目的不平衡。

还有一种情况，A 账户余额为 0，如果这个时候转账成功了，A 账户的余额会变成-1000，虽然它满足了原子性的，但是我们知道，借记卡的余额是不能够小于0的，所以也违反了一致性。用户自定义的完整性通常要在代码中控制。

### 2.3 隔离性（Isolation） ###

我们有了事务的定义以后，在数据库里面会有很多的事务同时去操作我们的同一张表或者同一行数据，必然会产生一些并发或者干扰的操作，那么我们对隔离性的定义，就是这些很多个的事务，对表或者行的并发操作，应该是透明的，互相不干扰的。

通过这种方式，我们最终也是保证业务数据的一致性。

### 2.4 持久性（Durable） ###

事务的持久性是什么意思呢？我们对数据库的任意的操作，增删改，只要事务提交成功，那么结果就是永久性的，不可能因为我们系统宕机或者重启了数据库的服务器，它又恢复到原来的状态了。这个就是事务的持久性。

持久性怎么实现呢？数据库崩溃恢复（crash-safe）是通过什么实现的？持久性是通过redo log和double write双写缓冲来实现的，我们操作数据的时候，会先写到内存的 buffer pool 里面，同时记录 redo log，如果在刷盘之前出现异常，在重启后就可以读取redo log的内容，写入到磁盘，保证数据的持久性。

当然，恢复成功的前提是数据页本身没有被破坏，是完整的，这个通过双写缓冲（double write）保证。

> ==> **原子性，隔离性，持久性，最后都是为了实现一致性。**

## 3.数据库如何操作事务？ ##

### 3.1 数据库什么时候会出现事务？ ###

无论是我们在 Navicat 的这种工具里面去操作，还是在我们的 Java 代码里面通过 API 去操作，还是加上@Transactional 的注解或者 AOP 配置，其实最终都是发送一个指令到数据库去执行，Java的JDBC只不过是把这些命令封装起来了。

我们先来看一下我们的操作环境。版本，存储引擎，事务隔离级别。

select version(); -- 5.7
    show variables like '%engine%'; -- InnnoDB
    show global variables like "tx_isolation"; -- RR

执行这样一条更新语句的时候，它有事务吗？

update student set sname='王五' where id=1;

实际上，它自动开启了一个事务，并且提交了，所以最终写入了磁盘。这个是开启事务的第一种方式，自动开启和自动提交。

> 在innodb里面， 所有的活动都是运行在事务里面的，如果autocommit=1，每个SQL语句都是一个事务，innodb默认autocommit=1的，意思就是MySQL会在每个语句执行的时候自动提交事务，当然是语句没有报错，如果报错了，那就会自动回滚rollback。所以在autocommit开启的情况下，每个insert ，update ，delete，都是一个事务，只不过没有显示声明开启事务。

### 3.2 如何开启关闭事务？ ###

InnoDB里面有一个autocommit的参数（分成两个级别， session级别和global级别）。

show variables like 'autocommit';

它的默认值是ON。autocommit这个参数是什么意思呢？是否自动提交。如果它的值是true/on的话，我们在操作数据的时候，会自动开启一个事务，和自动提交事务。否则，如果我们把autocommit设置成false/off，那么数据库的事务就需要我们手动地去开启和手动地去结束。

set autocommit = 'OFF'; -- 这只是session级别的关闭，全局关闭需要global

![在这里插入图片描述][20201101014238752.png_pic_center]

> MySQL默认操作模式就是autocommit自动提交模式。这就表示除非显式地开始一个事务，否则每个查询都被当做一个单独的事务自动执行。我们可以通过设置autocommit的值改变是否是自动提交autocommit模式。  
>   
> 所以，什么时候需要手动开启和提交事务？
> 
> 1.  在autocommit开的情况下，你又想多个语句凑成一个事务，就要显式的声明事务了，使用begin, 或者start transaction, 事务结尾使用commit, 或者rollback。
> 2.  autocommit=0,关闭了自动提交事务，那么整个对话里的所有语句就处于一个长事务，需要显式的commit或者rollback。

手动开启事务也有几种方式，一种是用`begin`；一种是用`start transaction`。那么怎么结束一个事务呢？我们结束也有两种方式，第一种就是提交一个事务，`commit`；还有一种就是`rollback`，回滚的时候，事务也会结束。还有一种情况，客户端的连接断开的时候，事务也会结束。当我们结束一个事务的时候，事务持有的锁就会被释放，无论是提交还是回滚。

如果我们用 begin 手工开启一个事务，执行 update，但是数据没有写入磁盘，因为事务还没有提交，这个时候 commit 一下，再刷新一下，OK，写入了。

## 4.事务并发会带来什么问题？ ##

当很多事务并发地去操作数据库的表或者行的时候，如果没有我们刚才讲的事务的Isolation隔离性的时候，会带来哪些问题呢？

### 4.1 脏读 ###

> 事务A读取到了事务B已经修改但尚未提交的数据，还在这个数据基础上做了操作。此时，如果B事务回滚，A读取的数据无效，不符合一致性要求。

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

我们有两个事务，一个是Transaction A，一个是Transaction B，在第一个事务里面，它首先通过一个where id=1的条件查询一条数据，返回name=Ada，age=16的这条数据。然后第二个事务，它同样地是去操作id=1的这行数据，它通过一个update的语句，把这行id=1的数据的age改成了18，但是注意，它**没有提交**。

这个时候，在第一个事务里面，它再次去执行相同的查询操作，发现数据发生了变化，获取到的数据age变成了18。那么，这种在一个事务里面，由于其他的时候修改了数据并且没有提交，而导致了前后两次读取数据不一致的情况，这种事务并发的问题，我们把它定义成什么？这种读取到其他事务未提交的数据的情况，我们把它叫做脏读。

### 4.2 不可重复读 ###

> 事务A读取到了事务B已经提交的修改数据，不符合隔离性

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

同样是两个事务，第一个事务通过id=1查询到了一条数据。然后在第二个事务里面执行了一个update操作，这里大家注意一下，执行了update以后它通过一个commit **提交了修改**。

然后第一个事务读取到了其他事务已提交的数据导致前后两次读取数据不一致的情况，就像这里，age到底是等于16 还是18，那么这种事务并发带来的问题，我们把它叫做什么？这种一个事务读取到了其他事务已提交的数据导致前后两次读取数据不一致的情况，我们把它叫做不可重复读。

### 4.3 幻读 ###

> 事务A读取到了事务B提交的新增数据，不符合隔离性

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

在第一个事务里面我们执行了一个范围查询，这个时候满足条件的数据只有一条。在第二个事务里面，它**插入了一行数据，并且提交了**。重点：插入了一行数据。在第一个事务里面再去查询的时候，它发现多了一行数据。这种情况，我们把它叫做什么呢？一个事务前后两次读取数据数据不一致，是由于其他事务插入数据造成的，这种情况我们把它叫做幻读。

不可重复读和幻读，的区别在那里呢？不可重复读是修改或者删除，幻读是插入。

> 小结：我们刚才讲了事务并发带来的三大问题，现在来总结一下。无论是脏读，还是不可重复读，还是幻读，它们都是数据库的**读一致性问题**，都是在一个事务里面前后两次读取出现了不一致的情况。
> 
>   
> 读一致性的问题，必须要由数据库提供一定的事务隔离机制来解决。就像我们去饭店吃饭，基本的设施和卫生保证都是饭店提供的。那么我们使用数据库，隔离性的问题也必须由数据库帮助我们来解决。

## 5.如何解决并发处理事务带来的问题？ ##

### 5.1 SQL92标准 ###

所以，就有很多的数据库专家联合制定了一个标准，也就是说建议数据库厂商都按照这个标准，提供一定的事务隔离级别，来解决事务并发的问题，这个就是SQL92标准。我们来看一下SQL92标准的[官网][Link 1]。 这里面有一张表格（搜索\_iso），里面定义了四个隔离级别。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 3]

右边的P1 P2 P3就是代表事务并发的3个问题，脏读，不可重复读，幻读。Possible代表在这个隔离级别下，这个问题有可能发生，换句话说，没有解决这个问题。Not Possible就是解决了这个问题。我们详细地分析一下这4个隔离级别是怎么定义的。

*  第一个隔离级别叫做：Read Uncommitted（未提交读），一个事务可以读取到其他事务未提交的数据，会出现脏读，所以叫做RU，它没有解决任何的问题。
 *  第二个隔离级别叫做：Read Committed（已提交读），也就是一个事务只能读取到其他事务已提交的数据，不能读取到其他事务未提交的数据，它解决了脏读的问题，但是会出现不可重复读的问题。
 *  第三个隔离级别叫做：Repeatable Read (可重复读)，它解决了不可重复读的问题，也就是在同一个事务里面多次读取同样的数据结果是一样的，但是在这个级别下，没有定义解决幻读的问题。
 *  最后一个就是：Serializable（串行化），在这个隔离级别里面，所有的事务都是串行执行的，也就是对数据的操作需要排队，已经不存在事务的并发操作了，所以它解决了所有的问题。

这个是SQL92的标准，但是不同的数据库厂商或者存储引擎的实现有一定的差异，比如Oracle里面就只有两种RC（已提交读）和Serializable（串行化）。那么InnoDB的实现又是怎么样的呢？

### 5.2 InnoDB 对隔离级别的支持 ###

在MySQL InnoDB里面，不需要使用串行化的隔离级别去解决所有问题。那我们来看一下MySQL InnoDB里面对数据库事务隔离级别的支持程度是什么样的。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 4]

InnoDB支持的四个隔离级别和SQL92定义的基本一致，**隔离级别越高，事务的并发度就越低**。唯一的区别就在于，InnoDB在RR的级别就解决了幻读的问题。这个也是InnoDB默认使用RR作为事务隔离级别的原因，既保证了数据的一致性，又支持较高的并发度。

### 5.3 如何设置事务隔离级别 ###

可以通过以下命令设置事务隔离级别：

set session transaction isolation level read uncommitted  -- 读未提交
    set session transaction isolation level read committed    -- 读已提交
    set session transaction isolation level repeatalbe read   -- 可重复读
    set session transaction isolation level serializable      -- 串行化

### 5.4 事务隔离级别怎么选？ ###

RU 和 Serializable 肯定不能用。为什么网上有些文章推荐有RC？RC和RR主要有几个区别：

1.  RR的间隙锁会导致锁定范围的扩大。
2.  条件列未使用到索引，RR锁表，RC锁行。
3.  RC的“半一致性”（semi-consistent）读可以增加update操作的并发性。

在RC中，一个update语句，如果读到一行已经加锁的记录，此时InnoDB返回记录最近提交的版本，由MySQL上层判断此版本是否满足 update的where条件。若满足(需要更新)，则MySQL会重新发起一次读操作，此时会读取行的最新版本(并加锁)。

实际上，如果能够正确地使用锁（避免不使用索引去加锁），只锁定需要的数据，用默认的RR级别就可以了。

> 所以，事务隔离级别的实现原理是什么？请看这篇[【MySQL】并发控制方案（LBCC，MVCC）及死锁问题分析][MySQL_LBCC_MVCC]…

[sql_MySQL]: https://blog.csdn.net/weixin_43935927/article/details/109324057
[https_dev.mysql.com_doc_refman_5.7_en_storage-engines.html]: https://dev.mysql.com/doc/refman/5.7/en/storage-engines.html
[20201101014238752.png_pic_center]: /images/20221120/fc4adee3a5e24aaf8599e3f9e58cd266.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center]: /images/20221120/1e828b0c0a4a4629a07c04ac4aecc246.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221120/d290299e94134e1781322093fd78ed12.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221120/4e59e4b38f8a41529e3c18cd7fe1dd6f.png
[Link 1]: http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221120/dac9e9ce523641359000975b25f2f5d5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221120/c5de527f30f74caeb3d0c5589eeeeb20.png
[MySQL_LBCC_MVCC]: https://blog.csdn.net/weixin_43935927/article/details/109438837