（四）MySQL 事务

欢迎访问

事务有哪些特性？

事务是由 MySQL 的引擎来实现的，我们常见的 InnoDB 引擎它是支持事务的。

不过并不是所有的引擎都能支持事务，比如 MySQL 原生的 MyISAM 引擎就不支持事务，也正是这样，所以大多数 MySQL 的引擎都是用 InnoDB。

事务看起来感觉简单，但是要实现事务必须要遵守 4 个特性，分别如下：

原子性（Atomicity）：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节，而且事务在执行过程中发生错误，会被回滚到事务开始前的状态，就像这个事务从来没有执行过一样，就好比买一件商品，购买成功时，则给商家付了钱，商品到手；购买失败时，则商品在商家手中，消费者的钱也没花出去。
一致性（Consistency）：是指事务操作前和操作后，数据满足完整性约束，数据库保持一致性状态。比如，用户 A 和用户 B 在银行分别有 800 元和 600 元，总共 1400 元，用户 A 给用户 B 转账 200 元，分为两个步骤，从 A 的账户扣除 200 元和对 B 的账户增加 200 元。一致性就是要求上述步骤操作后，最后的结果是用户 A 还有 600 元，用户 B 有 800 元，总共 1400 元，而不会出现用户 A 扣除了 200 元，但用户 B 未增加的情况（该情况，用户 A 和 B 均为 600 元，总共 1200 元）。
隔离性（Isolation）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致，因为多个事务同时使用相同的数据时，不会相互干扰，每个事务都有一个完整的数据空间，对其他并发事务是隔离的。也就是说，消费者购买商品这个事务，是不影响其他消费者购买的。
持久性（Durability）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

InnoDB 引擎通过什么技术来保证事务的这四个特性的呢？

持久性是通过 redo log （重做日志）来保证的；
原子性是通过 undo log（回滚日志）来保证的；
隔离性是通过 MVCC（多版本并发控制）或锁机制来保证的；
一致性则是通过持久性+原子性+隔离性来保证；

事务的隔离级别

数据库事务的隔离级别有4种，由低到高分别为Read Uncommited、Read Commited、Repeatable Read、Serializable。并发数据访问时可能会出现以下问题，3类数据读取问题（脏读、不可重复读、幻读）和2类数据更新问题（第1类丢失更新和第2类丢失更新）。

Read Uncommited，读未提交，即一个事务可以读取另一个未提交事务的数据；并发操作会导致脏读
Read Commited，读已提交，即一个事务要等到另一个事务提交后才能读取数据；解决脏读问题；并发操作会导致不可重复读
Repeatable Read，重复读，即开始读取数据（事务开启）时，不再允许修改操作；解决不可重复读问题；并发操作会导致幻读（对应insert操作）
Serializable，序列化，最高的事务隔离级别，该级别下，事务串行化顺序执行；避免脏读、不可重复读与幻读；但是该级别效率低下，比较消耗数据库性能，一般不用。

并发问题

**脏读：**一个事务读取另一个未提交的数据。

**不可重复读：**一个事务范围内两个相同的查询却返回了不同数据。（对应的是更新操作）

**幻读：**一个事务范围内两个相同的查询却返回了不同数据。（对应的是插入操作）
**第1类丢失更新：**两个事务均进行更新操作，相互影响，某一事务撤销影响最终结果的准确性。（撤销）

**第2类丢失更新：**事务A覆盖事务B已经提交的数据，造成事务B所做的操作丢失。（提交覆盖）

	第一类丢失更新	脏读	不可重复读	第二类丢失更新	幻读	备注
Read Uncommited	√
Read Commited	√	√				读取事务要等到这个更新操作事务提交后才能读取数据，可以解决脏读问题。（大多数数据库默认的隔离级别）
Repeatable Read	√	√	√	√		开始读取数据（事务开始）时，不允许修改操作（即update操作）。（MySQL的默认隔离级别）
Serializable	√	√	√	√	√	以上并发问题都不存在，但是效率低下，一般不用
			对应Update操作		对应insert操作

这四种隔离级别具体是如何实现的呢？

对于「读未提交」隔离级别的事务来说，因为可以读到未提交事务修改的数据，所以直接读取最新的数据就好了；
对于「串行化」隔离级别的事务来说，通过加读写锁的方式来避免并行访问；
对于「读提交」和「可重复读」隔离级别的事务来说，它们是通过 Read View 来实现的，它们的区别在于创建 Read View 的时机不同，大家可以把 Read View 理解成一个数据快照，就像相机拍照那样，定格某一时刻的风景。**「读提交」隔离级别是在「每个语句执行前」都会重新生成一个 Read View，而「可重复读」隔离级别是「启动事务时」**生成一个 Read View，然后整个事务期间都在用这个 Read View。

注意，执行「开始事务」命令，并不意味着启动了事务。在 MySQL 有两种开启事务的命令，分别是：

第一种：begin/start transaction 命令；
第二种：start transaction with consistent snapshot 命令；

这两种开启事务的命令，事务的启动时机是不同的：

执行了 begin/start transaction 命令后，并不代表事务启动了。只有在执行这个命令后，执行了第一条 select 语句，才是事务真正启动的时机；
执行了 start transaction with consistent snapshot 命令，就会马上启动事务。

MySQL InnoDB 引擎避免幻读现象

MySQL InnoDB 引擎的可重复读隔离级别（默认隔离级），根据不同的查询方式，分别提出了避免幻读的方案：

针对快照读（普通 select 语句），是通过 MVCC 方式解决了幻读。
针对当前读（select … for update 等语句，带锁的），是通过 next-key lock（记录锁+间隙锁）方式解决了幻读。

我举例了两个发生幻读场景的例子。

第一个例子：对于快照读， MVCC 并不能完全避免幻读现象。因为当事务 A 更新了一条事务 B 插入的记录，那么事务 A 前后两次查询的记录条目就不一样了，所以就发生幻读。

第二个例子：对于当前读，如果事务开启后，并没有执行当前读，而是先快照读，然后这期间如果其他事务插入了一条记录，那么事务后续使用当前读进行查询的时候，就会发现两次查询的记录条目就不一样了，所以就发生幻读。

所以，MySQL 可重复读隔离级别并没有彻底解决幻读，只是很大程度上避免了幻读现象的发生。

要避免这类特殊场景下发生幻读的现象的话，就是尽量在开启事务之后，马上执行 select … for update 这类当前读的语句，因为它会对记录加 next-key lock，从而避免其他事务插入一条新记录。

Read View 在 MVCC 里如何工作的？

Read View 有四个重要的字段：

m_ids ：指的是在创建 Read View 时，当前数据库中「活跃事务」的事务 id 列表，注意是一个列表，“活跃事务”指的就是，启动了但还没提交的事务。
min_trx_id ：指的是在创建 Read View 时，当前数据库中「活跃事务」中事务 id 最小的事务，也就是 m_ids 的最小值。
max_trx_id ：这个并不是 m_ids 的最大值，而是创建 Read View 时当前数据库中应该给下一个事务的 id 值，也就是全局事务中最大的事务 id 值 + 1；
creator_trx_id ：指的是创建该 Read View 的事务的事务 id。

)

一个事务去访问记录的时候，除了自己的更新记录总是可见之外，还有这几种情况：

如果记录的 trx_id 值小于 Read View 中的 min_trx_id 值，表示这个版本的记录是在创建 Read View 前已经提交的事务生成的，所以该版本的记录对当前事务可见。
如果记录的 trx_id 值大于等于 Read View 中的 max_trx_id 值，表示这个版本的记录是在创建 Read View 后才启动的事务生成的，所以该版本的记录对当前事务不可见。
如果记录的 trx_id 值在 Read View 的min_trx_id和max_trx_id之间，需要判断 trx_id 是否在 m_ids 列表中：
- 如果记录的 trx_id 在 m_ids 列表中，表示生成该版本记录的活跃事务依然活跃着（还没提交事务），所以该版本的记录对当前事务不可见。
如果记录的 trx_id 不在 m_ids列表中，表示生成该版本记录的活跃事务已经被提交，所以该版本的记录对当前事务可见。

这种通过「版本链」来控制并发事务访问同一个记录时的行为就叫 MVCC（多版本并发控制）。

读提交是如何工作的？

读提交隔离级别是在每次读取数据时，都会生成一个新的 Read View。

可重复读是如何工作的？

可重复读隔离级别是启动事务时生成一个 Read View，然后整个事务期间都在用这个 Read View。

问题自测

1.事务的四⼤特性了解么?

原子性（Atomicity）：一个事务中的所有操作，要么全部完成，要么全部不完成
一致性（Consistency）：是指事务操作前和操作后，数据满足完整性约束，数据库保持一致性状态。
隔离性（Isolation）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致
持久性（Durability）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

2.并发事务带来了哪些问题?不可重复读和幻读有什么区别？

**脏读：**一个事务读取另一个未提交的数据。
**不可重复读：**一个事务范围内两个相同的查询却返回了不同数据。（对应的是更新操作）
**幻读：**一个事务范围内两个相同的查询却返回了不同数据。（对应的是插入操作）
**第1类丢失更新：**两个事务均进行更新操作，相互影响，某一事务撤销影响最终结果的准确性。（撤销）
**第2类丢失更新：**事务A覆盖事务B已经提交的数据，造成事务B所做的操作丢失。（提交覆盖）

不可重复读指的是在同一事务中的两次读取操作之间，由于其他事务的修改导致了数据的不一致性，进而第二次读取得到的结果与第一次读取不同

幻读指的是在同一事务中的两次查询操作之间，由于其他事务的插入或删除操作导致了数据的变化，进而第二次查询得到的结果与第一次查询不同

3. MySQL 事务隔离级别？默认是什么级别？

Read Uncommited，读未提交，导致脏读，**实现：**直接读最新数据
Read Commited，读已提交，解决脏读问题，会导致不可重复读；**实现：在「每个语句执行前」**都会重新生成一个 Read View来实现
Repeatable Read，可重复读，即开始读取数据（事务开启）时，不再允许修改操作；解决不可重复读问题；会导致幻读（对应insert和delete操作），**实现：在「启动事务时」**生成一个 Read View，然后整个事务期间都在用这个 Read View来实现。
Serializable，序列化，最高的事务隔离级别，该级别下，事务串行化顺序执行；避免脏读、不可重复读与幻读；但是该级别效率低下，实现：加读写锁的方式来避免并行访问。

默认可重复读

4.MySQL 的隔离级别是基于锁实现的吗？

实现见问题3

5.InnoDB 对 MVCC 的具体实现

通过快照的方式实现

一个事务去访问记录的时候，除了自己的更新记录总是可见之外，还有这几种情况：

如果记录的 trx_id 值小于 Read View 中的 min_trx_id 值，表示这个版本的记录是在创建 Read View 前已经提交的事务生成的，所以该版本的记录对当前事务可见。
如果记录的 trx_id 值大于等于 Read View 中的 max_trx_id 值，表示这个版本的记录是在创建 Read View 后才启动的事务生成的，所以该版本的记录对当前事务不可见。
如果记录的 trx_id 值在 Read View 的min_trx_id和max_trx_id之间，需要判断 trx_id 是否在 m_ids 列表中：
- 如果记录的 trx_id 在 m_ids 列表中，表示生成该版本记录的活跃事务依然活跃着（还没提交事务），所以该版本的记录对当前事务不可见。
如果记录的 trx_id 不在 m_ids列表中，表示生成该版本记录的活跃事务已经被提交，所以该版本的记录对当前事务可见。