深入解析MySQL中的事务（上）

MySQL事务管理

一、事务的基本概念
二、事务的操作
三、事务的四大特性（ACID）
- 1. 原子性（Atomicity）
- 2. 持久性（Durability）

引言：

在数据库管理系统中，事务（Transaction）是一个非常重要的概念。它确保了一系列数据库操作的原子性、一致性、隔离性和持久性（通常简称为ACID属性）。MySQL作为广泛使用的关系型数据库管理系统，支持事务处理，这对于确保数据完整性和并发控制至关重要。接下来，我们将对MySQL中的事务及其四大特性进行深度剖析。

一、事务的基本概念

事务是一系列数据库操作的逻辑单元，这些操作要么全部执行，要么全部不执行，以保持数据库的完整性和一致性。事务的边界由用户明确指定，通常是通过SQL语句的开始（如START TRANSACTION）和提交（如COMMIT）或回滚（如ROLLBACK）来定义的。

为什么需要事务？

事务在数据库管理系统中起着至关重要的作用，它们的存在主要是为了解决在并发操作和数据更新过程中可能遇到的各种问题，从而确保数据的完整性和一致性。以下是为什么需要事务的几个关键原因：

1. 数据完整性

事务确保了一系列数据库操作的原子性，即这些操作要么全部成功执行，要么全部不执行。这是非常重要的，因为如果一个操作序列（例如转账操作）中的某个步骤失败，而其他步骤已经成功执行，那么数据就会处于不一致的状态。事务确保了在出现错误或异常情况时，数据库可以回滚到操作前的状态，从而保持数据的完整性。

2. 并发控制

在并发环境中，多个用户或应用程序可能同时尝试访问和修改相同的数据。如果没有适当的事务管理，这些并发操作可能会导致数据冲突和不一致。事务通过提供隔离性，确保了一个事务在修改数据时不会被其他事务干扰，从而避免了数据冲突和并发问题。

3. 错误恢复

在数据库操作中，可能会出现各种错误，如程序错误、网络故障或硬件故障等。如果没有事务，这些错误可能会导致数据库处于不一致的状态，并且可能需要手动修复或恢复。事务通过提供持久性和可恢复性，确保了在出现错误时，数据库可以恢复到一致的状态，并且可以通过日志记录来恢复丢失的数据。

4. 复杂业务逻辑的支持

许多业务逻辑操作需要跨越多个表或多个步骤，并且这些步骤必须作为一个整体来执行。例如，一个在线购物系统可能需要在用户购买商品时更新库存、创建订单、发送通知等。这些操作必须作为一个事务来执行，以确保它们要么全部成功，要么全部失败。事务提供了这种能力，支持复杂的业务逻辑操作，并确保数据的完整性和一致性。

5. 安全性

事务还可以提供安全性保障。通过限制对数据的并发访问和确保数据在更新过程中的一致性，事务可以防止未经授权的访问和数据篡改。这对于保护敏感数据和确保数据的安全性至关重要。

综上所述，事务在数据库管理系统中扮演着不可或缺的角色。它们通过确保数据的完整性、并发控制、错误恢复、支持复杂业务逻辑和提高安全性等方面，为数据库操作提供了强有力的保障。因此，在设计和开发数据库应用程序时，合理使用和管理事务是非常重要的。

为什么会出现事务

事务被 MySQL 编写者设计出来,本质是为了当应用程序访问数据库的时候,事务能够简化我们的编程模型,不需要我们去考虑各种各样的潜在错误和并发问题.可以想一下当我们使用事务时,要么提交,要么回滚,我们不会去考虑网络异常了,服务器宕机了,同时更改一个数据怎么办对吧?因此事务本质上是为了应用层服务的.而不是伴随着数据库系统天生就有的.

备注：我们后面把 MySQL 中的一行信息，称为一行记录

查看引擎是否支持事务

在MySQL中，SHOW ENGINES 命令用于列出当前MySQL服务器支持的所有存储引擎及其相关信息。
在这里插入图片描述
这个命令的结果集包含几个字段，每个字段都提供了关于存储引擎的特定信息。

以下是SHOW ENGINES结果集中常见字段的解析：

Engine：
- 描述：存储引擎的名称。
- 示例：InnoDB, MyISAM, MEMORY, CSV, BLACKHOLE, FEDERATED 等。
Support：
- 描述：表示MySQL服务器如何支持该存储引擎。
- 可能的值：
  - DEFAULT：这是MySQL的默认存储引擎（除非在配置文件中指定了其他引擎）。
  - YES：MySQL支持这个存储引擎，但它不是默认的。
  - NO：MySQL不支持这个存储引擎。
  - DISABLED：这个存储引擎在MySQL中被禁用了。
Comment：
- 描述：关于存储引擎的简短描述或注释。
- 示例：对于InnoDB，可能是 “Supports transactions, row-level locking, and foreign keys”。
Transactions：
- 描述：指示该存储引擎是否支持事务。
- 可能的值：YES 或 NO。
XA：
- 描述：指示该存储引擎是否支持分布式事务（即XA事务）。
- 可能的值：YES 或 NO。
Savepoints：
- 描述：指示该存储引擎是否支持保存点（savepoints）。保存点是事务中的一个点，允许你回滚到该点而不是整个事务的开始。
- 可能的值：YES 或 NO。
Data_links（在某些MySQL版本中可能不存在）：
- 描述：与存储引擎如何处理数据链接（例如，MyISAM中的.MYI文件）相关的某种信息。但现代MySQL版本可能不再显示此字段。
- 可能的值：（取决于具体的存储引擎）
Auto_commit：
- 描述：指示存储引擎是否支持自动提交模式。在自动提交模式下，每次SQL语句执行后都会自动提交事务。
- 可能的值：YES 或 NO（但通常所有存储引擎都支持自动提交）。
Commit：
- 描述：与存储引擎如何处理事务提交相关的某种信息（但现代MySQL版本可能不再显示此字段）。
- 可能的值：（取决于具体的存储引擎）
Rollback：
- 描述：与存储引擎如何处理事务回滚相关的某种信息（但现代MySQL版本可能不再显示此字段）。
- 可能的值：（取决于具体的存储引擎）

事务提交方式

在MySQL中，事务提交方式主要有两种：自动提交（Automatic Commit）和手动提交（Manual Commit）。这两种方式决定了事务边界以及何时将事务中的修改持久化到数据库中。

自动提交（Automatic Commit）

MySQL的事务默认是自动提交的。也就是说，当你执行一条DML（数据操纵语言，如INSERT、UPDATE、DELETE）语句时，MySQL会立即隐式地提交这个事务。这意味着每次单独的DML语句都被视为一个单独的事务，并且一旦执行成功，其修改就会立即生效。

手动提交（Manual Commit）

手动提交方式允许你控制事务的边界。你可以使用START TRANSACTION（或BEGIN）语句来明确一个事务的开始，然后执行一系列的DML语句。这些语句在事务中是作为一个整体来处理的，只有当你显式地调用COMMIT语句时，事务中的修改才会被持久化到数据库中。如果在事务执行过程中出现了错误或者你需要撤销事务中的修改，你可以调用ROLLBACK语句来撤销事务中的所有修改，使数据回到事务开始前的状态。

如何查看和设置事务提交方式

你可以通过以下SQL语句来查看当前的事务提交方式：

SELECT @@autocommit;

在这里插入图片描述

如果返回的结果是1，表示当前是自动提交模式；如果返回的结果是0，表示当前是手动提交模式。

你可以通过以下SQL语句来设置事务提交方式：

设置为自动提交模式：

SET @@autocommit = 1;

设置为手动提交模式：

SET @@autocommit = 0;

在设置为手动提交模式后，你需要显式地调用COMMIT或ROLLBACK语句来控制事务的提交或回滚。

小结

事务提交方式的选择取决于你的具体需求。如果你希望每次DML语句都立即生效，那么可以使用自动提交模式；如果你需要控制多个DML语句作为一个整体来执行，并且可以在必要时撤销这些修改，那么应该使用手动提交模式。

二、事务的操作

准备工作——设置隔离级别（后文会讲到）和建立测试表

为了更好地验证效果，我们将隔离级别设置为较低的READ UNCOMMITTED（读取未提交）
在这里插入图片描述

但是这里有一个问题——为什么我设置了隔离级别为READ UNCOMMITTED（读取未提交）但是查询还会出现两种不同的结果？（下文我们解答）

此时我们需要退出mysql客户端，重新登录才会生效
在这里插入图片描述
创建一个银行用户表

mysql> create table if not exists bank_account(
    -> id int primary key,
    -> name varchar(50) not null default '',
    -> blance decimal(10,2) not null default 0.0
    -> )ENGINE=InnoDB DEFAULT CHARSET=UTF8;

在这里插入图片描述

回滚与保存点演示

启动两个终端，左终端使用begin或start transaction命令启动一个事务，右终端查看银行用户表中的信息。如下：

tips：在MySQL中，BEGIN 和 START TRANSACTION
命令在功能上是等价的，它们都是用来开始一个新的事务。这两个命令在大多数数据库系统中都被广泛接受，并且在MySQL中，它们没有任何实质性的区别。

在这里插入图片描述
左终端中的事务使用savepoint命令创建一个保存点，然后继续向表中插入一条记录，这时在右终端中也能看到新插入的这条记录（由于我们将隔离级别设置成了读未提交，因此在左终端中的事务使用commit提交之前，在右终端中就能查看到事务向表中插入的记录。）。如下：
在这里插入图片描述
再次向左终端中的事务使用savepoint命令创建一个保存点，然后继续向表中插入一条记录，这时在右终端中也能看到新插入的这条记录。如下：

左终端中的事务使用rollback命令回滚到保存点，这时右终端在查看表中数据时就看不到刚才插入的第二条记录了。如下：
在这里插入图片描述
直接rollback则回到最初begin位置

begin会自动更改提交方式

在左终端中启动一个事务并向表中新插入一条记录，由于隔离级别是读未提交，因此在右终端中能够查询到新插入的这条记录。如下：在这里插入图片描述
如果左终端中的事务在提交之前与MySQL断开连接，那么MySQL依旧会自动让事务回滚到最开始，这时右终端中就看不到之前新插入的记录了。如下：

单条SQL与事务关系

实际全局变量autocommit是否被设置影响的是单条SQL语句，InnoDB中的每一条SQL都会默认被封装成事务。
autocommit为ON，则单条SQL语句执行后会自动被提交，如果为OFF，则SQL语句执行后需要使用commit进行手动提交。

通过上述示例我们不难看出，我们就算写一条简单的insert语句需要通过begin -> insert -> commit才能完成数据的持久保存，但是我们平时插入：
在这里插入图片描述
一条简单的insert语句也能实现持久化——即证明InnoDB中的每一条SQL都会默认被封装成事务。

再谈autocommit

关闭autocommit自动提交，此时再向表中插入数据——右边依然可以查看到插入数据
在这里插入图片描述
但是我们意外退出（ctrl+\）或者正常退出（quit）都会发现，此时我们的insert语句好像并不像平时一样有持久的作用，这样更验证了上述的InnoDB中的每一条SQL都会默认被封装成事务。

小结

好的，以下是关于BEGIN或START TRANSACTION命令、SAVEPOINT、ROLLBACK TO、ROLLBACK和COMMIT在数据库事务处理中的小结：

BEGIN 或 START TRANSACTION

这两个命令用于启动一个新的事务。在事务开始之后，所有执行的SQL语句都将被视为一个逻辑单元，直到遇到COMMIT或ROLLBACK命令。如果所有语句都成功执行，则通过COMMIT命令提交事务，使得所做的更改永久生效。如果在执行过程中遇到错误或需要撤销更改，则可以使用ROLLBACK命令。

SAVEPOINT

SAVEPOINT命令用于在事务中设置一个保存点。保存点是事务中的一个标记，它允许你在稍后的时间将事务回滚到该保存点的状态，而不是回滚到事务的开始。这对于在复杂事务中处理多个步骤时特别有用，因为你可以根据需要回滚到特定的步骤，而不是整个事务。

ROLLBACK TO

ROLLBACK TO命令用于将事务回滚到指定的保存点。这意味着，从该保存点之后的所有更改都将被撤销，但保存点之前的更改仍然保留。这对于在事务的某个中间步骤遇到错误并希望撤销该步骤及之后的所有更改时特别有用。

ROLLBACK

ROLLBACK命令用于撤销自事务开始以来的所有更改，并将数据库状态回滚到事务开始之前的状态。如果在事务中设置了保存点，并且没有使用ROLLBACK TO指定保存点，则ROLLBACK将回滚到事务的开始。

COMMIT

COMMIT命令用于提交事务，使自事务开始以来的所有更改永久生效。一旦事务被提交，就不能再回滚这些更改（除非使用其他机制，如备份和恢复）。在提交事务之前，其他数据库用户或事务可能看不到你所做的更改（这取决于事务的隔离级别）。

示例

以下是一个简单的示例，演示了如何在事务中使用SAVEPOINT、ROLLBACK TO、ROLLBACK和COMMIT：

BEGIN;

-- 初始状态
UPDATE your_table SET value = 100 WHERE id = 1;

-- 设置一个保存点
SAVEPOINT my_savepoint;

-- 进行一些更改
UPDATE your_table SET value = 200 WHERE id = 1;
UPDATE your_table SET value = 300 WHERE id = 2; -- 假设这行出现了错误

-- 遇到错误，决定回滚到保存点
ROLLBACK TO my_savepoint;

-- 再次确认状态
-- 此时id为1的记录的value应该为100，id为2的记录的value没有改变

-- 继续事务并修复错误
UPDATE your_table SET value = 200 WHERE id = 2;

-- 所有更改都正确，提交事务
COMMIT;

在这个示例中，我们首先在事务中设置了一个保存点，并在之后进行了一些更改。当遇到错误时，我们使用ROLLBACK TO命令将事务回滚到保存点的状态。然后，我们修复了错误并继续事务，最后使用COMMIT命令提交事务。

三、事务的四大特性（ACID）

1. 原子性（Atomicity）

原子性指的是事务作为一个整体来执行，包含在其中的对数据库的操作要么全部执行，要么全部不执行。事务的原子性是通过数据库的恢复机制来实现的，如果事务中的某个操作失败，那么系统有能力撤销事务中已经发生的所有操作，使数据库回到一个一致的状态。

示例：假设我们有一个银行账户转账操作，需要从账户A转账50元到账户B。这个操作包含两个步骤：从账户A减去50元，然后给账户B增加50元。如果这两个步骤不能作为一个整体来执行（即不具有原子性），那么可能会出现数据不一致的情况。例如，如果第一个步骤成功执行但第二个步骤失败，那么账户A的余额会错误地减少，而账户B的余额没有增加。为了避免这种情况，我们可以将这两个步骤放在一个事务中执行，确保它们要么都成功，要么都失败。

START TRANSACTION;
UPDATE bank_account SET blance = blance - 50 WHERE id = '1';
UPDATE bank_account SET blance = blance + 50 WHERE id = '2';
COMMIT;

在这里插入图片描述
如图，如果左边数据库突然断链接，那么右边则不会有数据（ctrl+z--挂起mysql ctrl+\ 模拟中断mysql服务）

这里看到，如果服务被突然中断，会回到begin之前的操作，体现了原子性（要么不做，要么做完）。

2. 持久性（Durability）

持久性指的是只要事务一旦提交，其所做的修改会永久地保存到数据库中，即使系统崩溃也不会丢失。这是通过数据库管理系统的日志和恢复机制来保证的。在MySQL中，当事务提交后，其更改会立即写入到磁盘上的数据文件中，并在后续的操作中持久化保存。
示例：一旦事务被提交，其对数据库中数据的更改就是永久性的，即使系统崩溃也不会丢失。为了演示这个特性，我们可以考虑一个银行账户转账操作的例子。假设我们已经成功地将50元从账户A转账到账户B，并且事务已经被提交。即使此时系统突然崩溃并重新启动，账户A的余额仍然会减少50元，而账户B的余额会增加50元。这是因为MySQL通过写日志和恢复机制来确保事务的持久性。
在这里插入图片描述
事务的隔离性和一致性请看下一篇章