MySQL之事务

今天药忘吃喽~ 2021-08-29 13:48 415阅读 0赞

### 事务 ###

*  1. 事务
 *   *  1.1 概述
     *   *  1.1.1 A（Atomicity）原子性
         *  1.1.2 C（Consistency）一致性
         *  1.1.3 I（Isolation）隔离性
         *  1.1.4 D（Durability）持久性
     *  1.2 分类
     *   *  1.2.1 扁平事务
         *  1.2.2 带有保存点的编排事务
         *  1.2.3 链事务
         *  1.2.4 嵌套事务
         *  1.2.4 分布式事务
 *  2. 事务的实现
 *   *  2.1 redo
     *  2.2 undo
 *  3. 事务控制语句
 *  4. 事务的隔离级别
 *  5. 分布式事务
 *   *  7.1 MySQL 分布式事务
     *  7.2 内部 XA 事务
 *  8. 不好的事务习惯

# 1. 事务 #

## 1.1 概述 ##

事务可由一条非常简单的`SQL`语句组成，也可以由一组复杂的`SQL`组成。

事务是访问并更新数据库中各种数据项的一个程序执行单元。

事务中的操作，要么全部成功，要么全都不成功。

事务必须同时满足四个特性：原子性、一致性、隔离性、持久性。

### 1.1.1 A（Atomicity）原子性 ###

原子性指整个数据库事务是不可分割的工作单位。只有使事务中所有的数据库操作都执行成功，才算整个事务成功。事务中任何一个`SQL`语句执行失败，已经执行成功的`SQL`必须撤销，数据库状态应该退回到事务前的状态。

以银行取钱为例：

1）登录 ATM 机平台，输入密码
    2）从银行的数据库中，取得账户的信息
    3）用户在ATM机上输入要提取的金额
    4）更新银行数据库中的账户信息
    5）ATM 出款
    6）用户取钱

整个取款过程应该被视为原子操作，即要么全做，要么全不做。不能用户钱未从 ATM 机取得，银行卡上的钱已经被扣除。

### 1.1.2 C（Consistency）一致性 ###

一致性指事务将数据库从一种状态转变为下一种一致的状态。在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。

例如表中一个字段具有唯一约束，如果一个事务对该字段进行修改，但是在事务提交或事务操作发生回滚后，该字段的数据不唯一了，这就破坏了事务的一致性要求，即事务将数据库从一种状态变为了一种不一致的状态。

事务是一致性的状态，如果事务中某个动作失败了，系统可以自动撤销事务 — 返回初始化的状态。

### 1.1.3 I（Isolation）隔离性 ###

事务隔离性要求每个读写事务的对象对其他事务的操作对象能相互分离，即该事务提交前对其他事务都不可见，通常使用锁来实现。

### 1.1.4 D（Durability）持久性 ###

事务一旦提交，其结果就是永久性的。即使发生宕机等故障也能恢复。

## 1.2 分类 ##

### 1.2.1 扁平事务 ###

在扁平事务中，所有操作都处于同一层次，其由 `BEGIN WORK` 开始，由 `COMMIT WORK` 或 `ROLLBACK WORK` 结束，其间的操作是原子的，要么都执行，要么都回滚。

扁平事务的主要限制是不能提交或者回滚事务的某一部分，或分几个步骤提交。

### 1.2.2 带有保存点的编排事务 ###

在扁平事务的基础上，允许事务执行过程中回滚到同一事务中较早的一个状态。因为某些事物可能在执行过程中出现的错误并不会导致所有的操作都无效，放弃整个事物不合乎要求，开销太大。

**保存点（SAVE WORK）**：用来通知系统记住事物当前的状态，以便当之后发生错误时，事务能回到保存点当时的状态。

对于扁平事务，其隐式的设置了一个保存点，在事务开始的时候，因此回滚只能回滚到事务开始时的状态。保存点用 `SAVE WORK` 函数建立，通知系统记录当前的处理状态。当出现问题时，保存点能用作内部的重启动点，根据应用逻辑，决定是回到最近一个保存点还是其他更早的保存点。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70]  
       当用`BEGIN WORK`开启一个事务时，隐式地包含了一个保存点，当事务通过 `ROLLBACK WORK ：2` 发出部分回滚命令时，事务回滚到保存点2，接着依次执行，并再次执行到 `ROLLBACK WORK ：5`，直到最后的`COMMIT WORK` 操作，这时表示事务结束。

此外，当事务通过ROLLBACK WORK ：2 发出部分回滚命令时，事务并没有完全被回滚，当前事务依然是活跃的。

### 1.2.3 链事务 ###

链事务可视为保存点模式的另一种实现。带有保存点的扁平事务，当发生系统崩溃时，所有保存点都将消失，因为其保存点是易失的，而非持久的。这意味着当进行恢复时，事务需要从开始处重新执行，而不能从最近的一个保存点执行。

链事务的思想是：在提交一个事务时，释放不需要的数据对象，将必要的处理上下文隐式地传送给下一个要开始地事务。注意，提交事务操作和开始下一个事务操作将合并为一个原子操作。这意味着下一个事务将看到上一个事务的结果，就好像在一个事务中进行一样。

### 1.2.4 嵌套事务 ###

嵌套事务是一个层次结构框架，由一个顶层事务控制着各个层次的事务，顶层事务之下嵌套的事务被称为子事务，其控制每一个局部的变换，结构如下：

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

### 1.2.4 分布式事务 ###

分布式事务通常是一个分布式环境下运行的扁平事务，因此需要根据数据所在位置访问网络中的不同节点。

最常见的场景就是跨行转账，各银行都有自己的数据库。

# 2. 事务的实现 #

隔离性是通过锁来实现。

`redo log`称为重做日志，用来保证原子性和持久性。

`undo log`用来保证一致性。

`redo`恢复提交事务修改的页操作，而`undo`回滚行记录到某个特定版本。因此两者记录的内容不同，`redo`通常是物理日志，记录的是页的物理修改操作。`undo`是逻辑日志，根据每行记录进行记录。

## 2.1 redo ##

当事务提交时，必须先将该事务的重做日志写入到重做日志文件中进行持久化，待事务的`COMMIT`操作完成才算完成。

为了确保每次日志都写入重做日志文件，在每次将重做日志缓冲写入重做日志文件后，InnoDB 都需要调用一次 fsync（同步内存中已修改的文件数据到磁盘） 操作。

## 2.2 undo ##

undo 是逻辑日志，因此只是将数据库逻辑地恢复到原来的样子。所有修改都被逻辑地取消了，但是数据结构和页本身在回滚之后可能大不相同。因为在多用户并发系统中，一个事务在修改当前一个页中某几条记录，同时还有别地事务在对同一个页另几条记录进行修改，因此，不能将一个页回滚到事务开始的样子，因为这样会影响其他事务正在进行地工作。

当InnoDB回滚时，它实际上做的是与先前相反的工作:

*  对于每个INSERT，InnoDB 会完成一个 DELETE
 *  对于每个DELETE，InnoDB 会完成一个INSERT
 *  对于每个UPDATE，InnoDB 会执行一个相反的UPDATE，将修改前的行放回去

除了回滚操作，`undo`的另一作用是`MVCC`。即当用户读取一行记录时，若该记录已经被其他事务占用，当前事务可以通过`undo`读取之前的行版本信息，以此实现非锁定读取。

# 3. 事务控制语句 #

*  START TRANSACTION | BEGIN : 显示开启一个事务
 *  COMMIT ： 提交事务，并使得已对数据库做的修改称为永久性
 *  ROLLBACK ：回滚会结束用户的事务，并撤销正在进行的所有未提交的修改
 *  SAVEPOINT identifier ：SAVEEPOINT 允许在事务中创建一个保存点，一个事务可以有多个 SAVEPOINT
 *  RELEASE SAVEPOINT identifier : 删除一个事务的保存点，当没有一个保存点时执行这条语句，会抛出异常
 *  ROLLBACK TO\[SAVEPOINT\] identifier ：将事务回滚到标记点，而不回滚标记点之前的任何工作
 *  SET TRANSACION ：设置事务的隔离级别

# 4. 事务的隔离级别 #

*  READ UNCOMMITED
 *  REAN COMMITED
 *  REPEATABLE READ
 *  SERIALIZABLE

`InnoDB`在`REPEATABLE READ`事务隔离级别下，使用`Next-Key Lock` 算法，因此避免幻读的产生。所以在该隔离级别下，已经达到了`SQL`标准的`SERIALIZABLE`隔离级别。

# 5. 分布式事务 #

## 7.1 MySQL 分布式事务 ##

分布式事务指允许多个独立的事务资源参与到一个全局的事务中。事务资源通常是关系型数据库系统，但也可以是对其他类型的资源。全局事务要求其中的所有参与事务要么都提交，要么都回滚。

使用分布式事务，InnoDB的事务隔离级别必须设置为 SERIALIZABLE 。

`XA` 事务允许不同数据库之间的分布式事务，如一个服务器是`MySQL`、另一台是 `Oracle` 以及 `SQL Server`。只要参与在全局事务中的每个节点都支持 `XA` 事务。

XA 事务由一个或多个资源管理器（Resource Managers）、一个事务管理器（Transaction Manager）以及一个应用程序（Application Program）组成。

*  资源管理器：提供给访问事务资源的方法。通常一个数据库就是一个资源管理器。
 *  事务管理器：协调参与全局事务中的各个事务，需要和参与全局事务的所有资源管理器进行通信。
 *  应用程序：定义事务的边界，指定全局事务中的操作。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 2]  
       **分布式事务使用两段式提交的方式**：

第一阶段，所有参与全局事务的节点都开始准备（`PREPARE`）。告诉事务管理器它们准备好提交了。

第二阶段，事务管理器告诉资源管理器执行 `ROLLBACK` 或 `COMMIT`。如果任何一个节点显示并未提交，则所有节点都要告知需要回滚。

## 7.2 内部 XA 事务 ##

上面所讨论的分布式事务是外部事物，即资源管理器是`MySQL`数据库本身。

在`MySQL`数据库还存在另外一种分布式事务，其在存储引擎于插件之间，又或者在存储引擎与存储引擎之间，称为内部 `XA` 事务。

最为常见的内部XA事务存在于`binlog` 与 `InnoDB` 之间。 **在事务提交时，先写二进制日志，再写与`InnoDB`存储引擎的重做日志。对上述两个操作的要求时原子的，即二进制日志和重做日志必须同时写入。若二进制日志先写了，而写入`InnoDB`存储引擎时发生宕机，那么`slave` 可能会接受到`master`传过去的 二进制日志并执行，最终导致了主从不一致**。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 3]  
       如果执行完 1、2 后在步骤 3 之前 `MySQL` 数据库发生了宕机，则会发生主从不一致的情况。

为解决该问题，MySQL 数据库在 binlog 与 InnoDB 之间采用 XA 事务。当事务提交时，InnoDB 会先做一个 PREPARE 操作，将事务的 xid 写入，接着进行二进制日志的写入。如果在InnoDB提交前，MySQL 宕机，那么 MySQL 会先检查准备的 UXID 是否已经提交，若没有，则在存储引擎层在进行一次提交操做。

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

# 8. 不好的事务习惯 #

1.  在循环中提交
2.  使用自动提交
3.  使用自动回滚
4.  长事务

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70]: /images/20210813/03dabb3d81af4a268dd17e4310e93216.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 1]: /images/20210813/2daeacf9e8484cc0802efeb50d4494c4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 2]: /images/20210813/e1f8d844faf14655a40a8ffc7f150305.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 3]: /images/20210813/4d0dc66b735a4355b529414c8c990168.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 4]: /images/20210813/2292dca5b2564ddb93ec48c271f72919.png