跳至主要內容

7-1. 使用事务

Victor Da V约 3685 字

Ⅰ. 事务介绍

事务是数据库区别于文件系统的重要特性之一，当我们有了事务就会让数据库始终保持一致性，同时我们还能通过事务的机制恢复到某个时间点，这样可以保证已提交到数据库的修改不会因为系统崩溃而丢失。

MySQL中，只有InnoDB是支持事务的。

1. 基本概念

事务是一组逻辑操作单元，使数据从一种状态变换到另一种状态。

事务处理的原则：保证所有事务都作为 一个工作单元 来执行，即使出现了故障，都不能改变这种执行方式。当在一个事务中执行多个操作时，要么所有的事务都被提交( commit )，那么这些修改就 永久 地保存下来；要么数据库管理系统将 放弃 所作的所有 修改 ，整个事务回滚( rollback )到最初状态。

举例：a给b转钱，a的钱扣了，b还没有加上，这时候发送了故障，就必须回滚。即一个操作要么成功，要么失败，没有中间状态。

2. ACID特性

ACID是事务的四大特性，在这四个特性中，原子性是基础，隔离性是手段，一致性是约束条件，而持久性是我们的目的。

数据库事务，其实就是数据库设计者为了方便起见，把需要保证原子性、隔离性、一致性和持久性的一个或多个数据库操作称为一个事务。

2.1 atomicity：原子性

原子性是指事务是一个不可分割的工作单位，要么全部提交，要么全部失败回滚。

比如：即要么转账成功，要么转账失败，是不存在中间的状态。如果无法保证原子性会怎么样?就会出现数据不一致的情形，A账户减去100元，而B账户增加100元操作失败，系统将无故丢失100元。

2.2 consistency：一致性

根据定义，一致性是指事务执行前后，数据从一个 合法性状态 变换到另外一个 合法性状态 。这种状态是语义上的而不是语法上的，跟具体的业务有关。

那什么是合法的数据状态呢？满足 预定的约束的状态就叫做合法的状态。通俗一点，这状态是由你自己来定义的（比如满足现实世界中的约束）。满足这个状态，数据就是一致的，不满足这个状态，数据就是不一致的！如果事务中的某个操作失败了，系统就会自动撤销当前正在执行的事务，返回到事务操作之前的状态。

比如：A账户200元，转账50元给B账户，A账户的钱扣了，但是B账户因为各种意外，余额并没有增加。你也知道此时数据是不一致的，为什么呢?因为你定义了一个状态，要求A+B的总余额必须不变。

2.3 isolation：隔离性

事务的隔离性是指一个事务的执行 不能被其他事务干扰 ，即一个事务内部的操作及使用的数据对 并发 的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。

示例：如果无法保证隔离性会怎么样？假设A账户有200元，B账户0元。A账户往B账户转账两次，每次金额为50元，分别在两个事务中执行。

UPDATE accounts SET money = money - 50 WHERE NAME = 'AA';
UPDATE accounts SET money = money + 50 WHERE NAME = 'BB';

如果无法保证隔离性，会出现下面的问题

7-1-1
7-1-1

2.4 durability：持久性

持久性是指一个事务一旦被提交，它对数据库中数据的改变就是 永久性的 ，接下来的其他操作和数据库故障不应该对其有任何影响。

持久性是通过 事务日志来保证的。日志包括了重做日志 和回滚日志 。

当我们通过事务对数据进行修改的时候，首先会将数据库的变化信息记录到重做日志中，然后再对数据库中对应的行进行修改。这样做的好处是，即使数据库系统崩溃，数据库重启后也能找到没有更新到数据库系统中的重做日志，重新执行，从而使事务具有持久性。

3. 事务的状态

MySQL根据事务操作执行的不同阶段把事务大致分成以下几个状态

  • 活动的（active）：事务对应的数据库操作正在执行过程中时，我们就说该事务处在 活动的 状态。
  • 部分提交的（partially committed）：当事务中的最后一个操作执行完成，但由于操作都在内存中执行，所造成的影响并 没有刷新到磁盘时，我们就说该事务处在 部分提交的 状态。
  • 失败的（failed）：当事务处在 活动的 或者 部分提交的 状态时，可能遇到了某些错误（数据库自身的错误、操作系统错误或者直接断电等）而无法继续执行，或者人为的停止当前事务的执行，我们就说该事务处在 失败的 状态。
  • 中止的（aborted）：如果事务执行了一部分而变为 失败的 状态，那么就需要把已经修改的事务中的操作还原到事务执行前的状态。换句话说，就是要撤销失败事务对当前数据库造成的影响。我们把这个撤销的过程称之为 回滚 。当 回滚 操作执行完毕时，也就是数据库恢复到了执行事务之前的状态，我们就说该事务处在了 中止的 状态。
  • 提交的（committed）：当一个处在 部分提交的 状态的事务将修改过的数据都 同步到磁盘 上之后，我们就可以说该事务处在了提交的状态。
7-1-2
7-1-2

图中可见，只有当事务处于提交的或者中止的状态时，一个事务的生命周期才算是结束了。对于已经提交的事务来说，该事务对数据库所做的修改将永久生效，对于处于中止状态的事务，该事务对数据库所做的所有修改都会被回滚到没执行该事务之前的状态。

4. 事务分类

从事务理论的角度来看，可以把事务分为五种类型

4.1 Flat Transactions：扁平事务

最普通的事务类型，开启事务->DML操作->提交事务，会中止事务

4.2 Flat Transactions with Savepoints：带有保存点的扁平事务

比偏平事务，多了设立保存点，除了回滚中止事务外，多了个回滚到保存点

4.3 Chained Transactions：链事务

一个事务由多个子事务链式组成，它可以被视为保存点模式的一个变种。

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

  • 带有保存点的扁平事务能回滚到任意正确的保存点，而链事务中的回滚仅限于当前事务，即只能恢复到最近的一个保存点。
  • 对于锁的处理，链事务在执行COMMIT后即释放了当前所持有的锁，而带有保存点的扁平事务不影响迄今为止所持有的锁。

4.4 Nested Transactions：嵌套事务

嵌套的事务，有一个顶层事务，控制着各个子事务。

4.5 Distributed Transactions：分布式事务

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

例如，一个银行用户从招商银行的账户向工商银行的账户转账1000元，这里需要用到分布式事务，因为不能仅调用某一家银行的数据库就完成任务。

Ⅱ. 基本用法

1. 使用步骤

  • ①开启事务
  • ②一系列DML操作
  • ③结束事务
    • 提交：commit 或
    • 中止（事务异常）：ROLLBACK

2. 显式事务

事务中的操作主要是DML（DDL操作一旦执行，都会自动提交）

2.1 开启事务

START TRANSACTION 或者 BEGIN ，作用是显式开启一个事务。

BEGIN;

-- 或者
START TRANSACTION;

START TRANSACTION语句相较于BEGIN特别之处在于，后边能跟随几个修饰符 ：

  • READ ONLY ：标识当前事务是一个 只读事务 ，也就是属于该事务的数据库操作只能读取数据，而不能修改数据。
  • READ WRITE ：标识当前事务是一个 读写事务 ，也就是属于该事务的数据库操作既可以读取数据，也可以修改数据。
  • WITH CONSISTENT SNAPSHOT ：启动一致性读

如果不显式指定事务的访问模式，那么该事务的访问模式就是读写模式。

2.2 提交事务

当提交事务后，对数据库的修改是永久性的。

COMMIT;

2.3 回滚事务

即撤销正在进行的所有没有提交的修改

-- 回滚到修改前
ROLLBACK;

-- 回滚到某个保存点
ROLLBACK TO [SAVEPOINT]

3. SAVEPOINT 保存点

在事务中创建保存点，方便后续针对保存点进行回滚，一个事务中可以存在多个保存点。

注意：提交之前才能回滚，只能向后回滚，不能向前回滚。

-- 创建保存点
SAVEPOINT 保存点名称

-- 删除某个保存点
RELEASE SAVEPOINT 保存点名称

-- 回滚到某个保存点
ROLLBACK TO [SAVEPOINT]

4. 隐式事务

隐式事务是可以自动提交的事务。

MySQL中有一个系统变量 autocommit。默认情况下，如果我们不显式的使用START TRANSACTION 或者 BEGIN 语句开启一个事务，那么每一条语句都算是一个独立的事务，这种特性称之为事务的自动提交。

-- 查看是否开启了自动提交
SHOW VARIABLES LIKE 'autocommit';

4.1 关闭自动提交

方式1：显式的的使用 START TRANSACTION 或者 BEGIN 语句开启一个事务。这样在本次事务提交或者回滚前会暂时关闭掉自动提交的功能。

方式2：把系统变量 autocommit 的值设置为 OFF ，如以下SQL指令：

SET autocommit = OFF;

-- 或
SET autocommit = 0;

这样的话，我们写入的多条语句就算是属于同一个事务了，直到我们显式的写出 COMMIT语句来把这个事务提交掉，或者显式的写出ROLLBACK语句来把这个事务回滚掉。

4.2 隐式提交（自动提交）数据的情况

MySQL中所有的操作本质上都是事务，都需要提交，只是大部分都自动提交了。

以下操作会自动提交事务。

  • 数据定义语言（Data definition language，缩写为：DDL）
    • 使用CREATE、ALTER、DROP等语句去修改数据库对象（库、表、视图、储存过程）时。
  • 隐式使用或修改mysql数据库中的表
    • 使用ALTER USER、CREATE USER、DROP uSER、GRANT、RENAME uSER、REvoKE、SETPASSWORD等语句时就会隐式的提交前边语句所属的事务。
  • 事务控制或关于锁定的语句
    • 在一个事务还没提交或者回滚时就又使用 START TRANSACTION 或者 BEGIN 语句开启了另一个事务时就会隐式的提交前边语句所属的事务。
    • 当前的 autocommit 系统变量的值为 OFF ，我们手动把它调为 ON 时，
    • 使用 LOCK TABLES 、 UNLOCK TABLES 等关于锁定的语句也会隐式的提交 前边语句所属的事务。
  • 加载数据的语句
    • 使用LOAD DATA语句来批量往数据库中导入数据时，也会隐式的提交前边语句所属的事务。
  • 关于MySQL复制的一些语句
    • 使用START SLAVE、STOP SLAVE、RESET SLAVE、CHANGE MASTER TO等语句时会隐式的提交前边语句所属的事务。
  • 其它的一些语句
    • 使用ANALYZE TABLE、CACHE INDEX、CHECK TABLE、FLUSH、LOAD INDEX INTO CACHE、OPTIMIZE TABLE、REPAIR TABLE、RESET等语句也会隐式的提交前边语句所属的事务。
  • 关闭连接时，会自动提交。

4.3 显示提交与隐式提交总结

显示提交：当我们设置 autocommit=1 时（默认），每条 SQL 语句都会自动进行提交。 不过这时，如果你采用 STARTTRANSACTION 或者 BEGIN 的方式来显式地开启事务，那么这个事务只有在 COMMIT 时才会生效，在 ROLLBACK 时才会回滚。

隐式提交：当我们设置 autocommit=0 时，不论是否采用 START TRANSACTION 或者 BEGIN 的方式来开启事务，都需要用 COMMIT 进行提交，让事务生效，使用 ROLLBACK 对事务进行回滚。

5. 链式事务

MySQL参数 completion_type 用来设置链式事务参数值如下：

  • completion=0，这是默认情况。当我们执行COMMIT的时候会提交事务，在执行下一个事务时，还需要使用START TRANSACTION 或者BEGIN 来开启。
  • completion=1，这种情况下，当我们提交事务后，相当于执行了CONMIT AND CHALIN，也就是开启一个链式事务，即当我们提交事务之后会开启一个相同隔离级别的事务。
  • completion=2，这种情况下CONMIT=CONNIT AND RELEASE，也就是当我们提交后，会自动与服务器断开连接。
-- 设置参数的值
SET @@completion_type = 1;

使用示例

CREATE TABLE user(name varchar(255), PRIMARY KEY (name)) ENGINE=InnoDB;

--开启链式事务
SET @@completion_type = 1; 

-- 开启事务
BEGIN; 
INSERT INTO user SELECT '张三';
-- 提交事务，同时自动开启了一个新的事务
COMMIT;

INSERT INTO user SELECT '李四';
INSERT INTO user SELECT '李四';
-- 回滚成功，如果不是设置了链式事务，这个回滚是无效的
ROLLBACK; 

-- 只有张三这一个值
SELECT * FROM user;