浅谈 MySQL 事务的基本概念与应用_mysql 事务在实际中的应用-优快云博客

本文链接：https://blog.youkuaiyun.com/m0_74109105/article/details/147177229

前言

在使用 MySQL 数据库进行开发的过程中，事务是一个非常重要的概念。正确理解和使用事务，能够有效保证数据的一致性和完整性，尤其是在并发访问数据的场景下。本文将从事务的基本概念出发，系统地介绍 MySQL 事务的特性、状态以及相关操作，帮助开发者更好地掌握这一关键技术。

注：为提高文章可读性，本文中所有 MySQL 语法关键词均使用小写形式。

事务的概念

MySQL 事务是一个或多个数据库操作的集合，这些操作要么全部执行成功，要么全部失败回滚。在数据库内部，事务是通过事务日志来实现的，包括重做日志（redo log）和撤销日志（undo log）。

简单来说，事务保证了数据库操作的"全或无"，不存在部分成功的情况，这对于保证数据的一致性至关重要。

事务的实现原理

MySQL 的 InnoDB 存储引擎通过以下机制实现事务功能：

redo log（重做日志）：记录事务修改的数据，用于持久化和崩溃恢复，确保事务的持久性。redo log 是物理日志，记录了"在某个数据页上做了什么修改"。
undo log（撤销日志）：记录事务执行前的数据状态，用于事务回滚和 MVCC（多版本并发控制），保证事务的原子性和隔离性。undo log 是逻辑日志，记录了"如何撤销某个操作"。
锁机制：通过各种锁（如行锁、表锁、意向锁等）确保并发事务的隔离性。
MVCC（多版本并发控制）：通过保存数据的多个版本，使得事务可以在不加锁的情况下读取数据，提高并发性能。

这些机制共同工作，确保了事务的 ACID 特性得以实现。

事务的特性（ACID）

MySQL 事务具有四个重要的特性，通常被称为 ACID 特性：

原子性（Atomicity）

事务中的所有操作作为一个整体，要么全部执行成功，要么全部失败回滚。如果事务中任何一个操作失败，整个事务就会回滚到执行前的状态，就像这个事务从来没有执行过一样。

原子性由 undo log（撤销日志）保证。当事务需要回滚时，MySQL 会利用 undo log 中的信息将数据恢复到事务执行前的状态。

一致性（Consistency）

事务执行前后，数据库从一个一致性状态转变为另一个一致性状态。一致性确保了事务对数据库的修改是符合预定规则的，不会破坏数据库的完整性约束。

一致性是事务的根本目的，其实现依赖于原子性、隔离性和持久性，以及应用程序正确的业务逻辑。例如，在转账操作中，无论事务成功与否，账户总额应该保持不变。

隔离性（Isolation）

多个事务并发执行时，一个事务的执行不应该被其他事务干扰。隔离性确保了并发执行的事务之间相互隔离，防止出现数据不一致的情况。

MySQL 支持四种隔离级别：

读未提交（Read Uncommitted）：允许读取未提交的数据变更，可能会导致脏读、不可重复读和幻读问题。
读提交（Read Committed）：只允许读取已提交的数据，可以避免脏读，但仍可能出现不可重复读和幻读问题。
可重复读（Repeatable Read）：MySQL 的默认隔离级别，确保同一事务中多次读取同样的记录结果一致，可以避免脏读和不可重复读，但在某些情况下仍可能出现幻读。
串行化（Serializable）：最高的隔离级别，通过强制事务串行执行，避免了脏读、不可重复读和幻读问题，但并发性能最差。

隔离级别越高，数据一致性越好，但并发性能越低。在 MySQL 的 InnoDB 存储引擎中，隔离性通过锁机制和 MVCC 实现。

事务并发问题详解

在不同的隔离级别下，可能会出现以下并发问题：

脏读（Dirty Read）：一个事务读取了另一个未提交事务修改的数据。

示例：

事务 A 修改了一行数据但未提交
事务 B 读取了这行数据
事务 A 回滚
导致事务 B 读取到了实际上不存在的数据

不可重复读（Non-repeatable Read）：一个事务内多次读取同一数据，但由于其他事务的修改提交，导致两次读取的结果不同。

示例：
```
事务 A 读取了一行数据
事务 B 修改了这行数据并提交
事务 A 再次读取这行数据，发现数据已变化
```
幻读（Phantom Read）：一个事务在读取某个范围的记录时，另一个事务在该范围内插入了新记录，导致第一个事务再次读取该范围记录时，发现有新记录"幻影"。

示例：
```
事务 A 查询 id>10 的所有记录
事务 B 插入一条 id=15 的记录并提交
事务 A 再次查询 id>10 的所有记录，结果集中出现了新记录
```

各隔离级别对并发问题的防护能力：

隔离级别	脏读	不可重复读	幻读
读未提交	可能发生	可能发生	可能发生
读提交	不会发生	可能发生	可能发生
可重复读	不会发生	不会发生	可能发生
串行化	不会发生	不会发生	不会发生

注：MySQL 的 InnoDB 引擎在可重复读隔离级别下通过间隙锁（gap lock）机制，在大多数情况下可以避免幻读问题。

持久性（Durability）

一旦事务提交，其对数据库的修改就是永久性的，即使系统崩溃也不会丢失这些更改。持久性通过将事务日志写入持久存储介质来实现。

MySQL 通过 redo log（重做日志）实现持久性。当事务提交时，所有修改都会被记录到 redo log 中，并持久化到磁盘。即使数据库崩溃，重启后也可以通过 redo log 恢复未写入数据文件的更改。

事务的状态

在 MySQL 中，事务会经历以下几个状态：

活动的（Active）

事务执行过程中的状态。当事务正在执行数据库操作时，处于活动状态。

在这个阶段，事务可以执行 SELECT、INSERT、UPDATE、DELETE 等操作，这些操作的结果仅对当前事务可见，对其他事务不可见（除非在"读未提交"隔离级别下）。

部分提交的（Partially Committed）

当事务中的最后一个操作执行完成，但结果仍在内存中，尚未写入磁盘时，处于部分提交状态。

在这个阶段，事务的所有操作已经完成，但是事务的结果还没有被持久化。系统崩溃可能导致这些更改丢失。

失败的（Failed）

当事务在活动或部分提交状态遇到错误（如数据库错误、系统错误或断电）而无法继续执行时，处于失败状态。

错误可能来自多种源，如：

违反数据库约束（如唯一键约束）
死锁检测导致事务被选为牺牲者
系统资源不足
显式调用 ROLLBACK 语句

中止的（Aborted）

当失败的事务完成回滚操作，数据库恢复到事务执行前的状态时，处于中止状态。

在这个阶段，系统已经通过 undo log 撤销了事务所做的所有修改，数据库回到了事务开始前的一致状态。

提交的（Committed）

当部分提交的事务将所有修改持久化到磁盘后，处于提交状态。

在这个阶段，事务的所有变更已经被永久保存，并对其他事务可见。即使系统崩溃，这些变更也不会丢失。

只有当事务处于"提交的"或"中止的"状态时，事务的生命周期才算结束。提交的事务对数据库的修改将永久生效，而中止的事务所做的所有修改都会被回滚。

事务的基本操作

MySQL 中进行事务操作主要涉及以下几个命令：

开启事务

有两种方式可以开启事务：

begin;
-- 或者
start transaction [修饰符];

其中 start transaction 可以接受以下修饰符：

read only：只读事务，不允许修改操作
read write：读写事务（默认）
with consistent snapshot：使用一致性快照读，在可重复读隔离级别下特别有用

例如：

start transaction read only;
-- 此时执行修改操作会报错
update account set balance = balance + 30 where id = 2; -- 这会产生错误

提交事务

commit;

执行 commit 后，事务的所有修改将被永久保存到数据库中。具体过程是：

将所有未刷新到磁盘的数据页刷新到磁盘
将事务从活动事务列表中删除
将一个提交记录写入重做日志文件
释放事务持有的锁

回滚事务

rollback;

执行 rollback 会撤销事务中所有未提交的修改，使数据库恢复到事务开始前的状态。具体过程是：

通过 undo log 撤销事务对数据所做的修改
将事务从活动事务列表中删除
释放事务持有的锁

事务的实际应用示例

假设我们有一个银行账户表 account，包含用户账户和余额信息：

create table account (
    id int(10) auto_increment,
    name varchar(30),
    balance int(10),
    primary key (id)
);

insert into account(name, balance) values('张三', 100), ('李四', 10);

现在，假设要执行一个转账操作，从张三的账户转 30 元到李四的账户：

-- 开始事务
begin;

-- 从张三账户减去30元
update account set balance = balance - 30 where id = 1;

-- 查看当前状态
select * from account;
/* 结果如下：
+----+--------+---------+
| id | name   | balance |
+----+--------+---------+
|  1 | 张三   |      70 |
|  2 | 李四   |      10 |
+----+--------+---------+
2 rows in set (0.00 sec)
*/

-- 给李四账户增加30元
update account set balance = balance + 30 where id = 2;

-- 查看更新后的状态
select * from account;
/* 结果如下：
+----+--------+---------+
| id | name   | balance |
+----+--------+---------+
|  1 | 张三   |      70 |
|  2 | 李四   |      40 |
+----+--------+---------+
2 rows in set (0.00 sec)
*/

-- 确认无误，提交事务
commit;

如果在操作过程中发现错误，可以回滚事务：

-- 发现转账金额错误
rollback;

-- 查看回滚后的状态，应该回到初始状态
select * from account;
/* 结果恢复为：
+----+--------+---------+
| id | name   | balance |
+----+--------+---------+
|  1 | 张三   |     100 |
|  2 | 李四   |      10 |
+----+--------+---------+
2 rows in set (0.00 sec)
*/

事务在业务场景中的应用

事务在多种业务场景中都至关重要，以下是一些典型应用：

银行转账：如上例所示，确保资金从一个账户转到另一个账户的原子性，避免出现资金丢失或双重记账。
库存管理：在电商系统中，当用户下单时，需要减少商品库存并创建订单记录，这两个操作要么都成功，要么都失败。
用户注册：创建用户记录、初始化用户配置、分配默认权限等多个相关操作需要作为一个整体执行。
订单处理：创建订单、扣减库存、处理支付等操作需要在一个事务中完成，以确保数据一致性。

事务的保存点

在复杂的事务中，有时我们希望能回滚部分操作而不是整个事务。MySQL 提供了保存点（Savepoint）功能来实现这一需求。

保存点的基本操作

-- 创建保存点
savepoint 保存点名称;

-- 回滚到保存点
rollback to [savepoint] 保存点名称;

-- 删除保存点
release savepoint 保存点名称;

保存点示例

-- 开始事务
begin;

-- 从张三账户减去20元
update account set balance = balance - 20 where id = 1;

-- 创建保存点
savepoint point1;

-- 查看当前状态
select * from account;
/* 结果如下：
+----+--------+---------+
| id | name   | balance |
+----+--------+---------+
|  1 | 张三   |      80 |
|  2 | 李四   |      10 |
+----+--------+---------+
2 rows in set (0.00 sec)
*/

-- 给李四账户增加30元（错误操作）
update account set balance = balance + 30 where id = 2;

-- 查看当前状态
select * from account;
/* 结果如下：
+----+--------+---------+
| id | name   | balance |
+----+--------+---------+
|  1 | 张三   |      80 |
|  2 | 李四   |      40 |
+----+--------+---------+
2 rows in set (0.00 sec)
*/

-- 发现错误，回滚到保存点
rollback to point1;

-- 查看回滚后的状态，应该只有张三账户减少了20元
select * from account;
/* 结果恢复为：
+----+--------+---------+
| id | name   | balance |
+----+--------+---------+
|  1 | 张三   |      80 |
|  2 | 李四   |      10 |
+----+--------+---------+
2 rows in set (0.01 sec)
*/

-- 给李四账户正确地增加20元
update account set balance = balance + 20 where id = 2;

-- 提交事务
commit;

保存点使我们能够在一个事务中设置多个"检查点"，在需要时可以回滚到特定的检查点，而不必回滚整个事务。这在执行复杂操作时特别有用。

保存点的注意事项

保存点只在当前事务中有效，事务提交或回滚后，保存点自动释放。
如果在同一事务中创建了同名的保存点，后创建的会覆盖先创建的。
回滚到某个保存点后，这个保存点之后创建的所有保存点会自动释放。
保存点是事务内部的概念，不应该依赖保存点来设计业务逻辑，应该尽量保持事务的简单和短小。

事务的自动提交

MySQL 默认开启了自动提交（autocommit）模式，即每个 SQL 语句都被视为一个独立的事务，执行后自动提交。

查看和修改自动提交状态

-- 查看自动提交状态
show variables like 'autocommit';
/* 可以看到默认时候打开的
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit    | ON    |
+---------------+-------+
1 row in set (0.02 sec)
*/

-- 关闭自动提交
set autocommit = off;

-- 开启自动提交
set autocommit = on;

当 autocommit 设置为 off 时，必须显式使用 commit 提交事务或 rollback 回滚事务。

自动提交模式的影响

autocommit = on（默认）：
- 每个独立的 SQL 语句视为一个事务，执行后自动提交
- 显式开始的事务（通过 begin 或 start transaction）需要显式 commit 或 rollback
- 大多数应用程序使用这种模式，简化了事务管理
autocommit = off：
- 所有语句都在一个事务中，直到显式提交或回滚
- 一个事务结束后，新的事务自动开始
- 提高了性能，但增加了管理复杂性和死锁风险

在实际应用中，推荐保持默认的自动提交模式（autocommit = on），并在需要事务的地方显式开启事务，这样可以减少出错的可能性。

隐式提交的情况

即使开启了事务或关闭了自动提交，某些 SQL 语句执行后也会导致当前事务的隐式提交。主要包括：

数据定义语言（DDL）语句：
- create, alter, drop 表或数据库
- truncate table
- rename table
- create, drop 索引
用户账户管理语句：
- alter user
- create user
- drop user
- grant
- rename user
- revoke
- set password
事务控制语句：
- 在一个事务未提交时开启另一个事务
- 将 autocommit 从 off 更改为 on
加载数据的语句：
- load data infile
锁定表的语句：
- lock tables
- unlock tables
管理语句：
- analyze table
- cache index
- check table
- flush
- optimize table
- repair table
- reset

在编写事务时，应避免在事务中执行这些会导致隐式提交的语句，否则可能会导致事务边界不清晰，引发意外的数据一致性问题。

隐式提交的示例

begin;
-- 开始一个事务

update account set balance = balance - 10 where id = 1;
-- 这是事务的一部分

create table temp (id int);
-- 这会导致前面的 update 被隐式提交

rollback;
-- 这个回滚不会撤销 update 操作，因为它已经被提交了

强烈建议亲手去试一下，每次输入命令都查询一下，看看数据的变化。

事务在不同存储引擎中的支持

需要注意的是，MySQL 中只有 InnoDB 和 NDB Cluster 存储引擎支持事务，而 MyISAM 存储引擎不支持事务。因此，如果需要使用事务功能，请确保相关表使用的是 InnoDB 存储引擎。

可以通过以下命令查看表的存储引擎：

show table status where Name = '表名';
/* 以下为我的结果：
+---------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+------------+--------------------+----------+----------------+---------+
| Name    | Engine | Version | Row_format | Rows | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time         | Update_time         | Check_time | Collation          | Checksum | Create_options | Comment |
+---------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+------------+--------------------+----------+----------------+---------+
| account | InnoDB |      10 | Dynamic    |    2 |           8192 |       16384 |               0 |            0 |         0 |              3 | 2025-04-05 19:15:12 | 2025-04-05 19:19:47 | NULL       | utf8mb4_0900_ai_ci |     NULL |                |         |
+---------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+------------+--------------------+----------+----------------+---------+
1 row in set (0.01 sec)
*/

存储引擎的对比

特性	InnoDB	MyISAM	Memory
事务支持	是	否	否
外键支持	是	否	否
全文索引	是(5.6+)	是	否
锁粒度	行锁	表锁	表锁
存储限制	64TB	文件系统限制	RAM
B-tree 索引	是	是	是
散列索引	否	否	是
数据缓存	是	否	是
压缩数据	是	是	否

如果应用需要事务支持和高并发，应选择 InnoDB 存储引擎。

事务的性能考量

虽然事务提供了数据一致性保证，但不当使用也会带来性能问题：

长事务的影响

长时间运行的事务会导致以下问题：

锁定资源时间长：阻塞其他会话访问相同数据，降低并发性能。
回滚段（undo log）过大：每个事务的修改都需要在回滚段中保存原始数据，长事务可能产生大量回滚数据。
MVCC 版本链过长：长事务持续期间，数据行的所有变更都需要保留，导致历史版本堆积。
容易引发死锁：长事务持有锁的时间长，增加了与其他事务发生锁冲突的可能性。

优化建议

控制事务大小和持续时间：
- 尽量减少事务中的 SQL 语句数量
- 避免在事务中进行用户交互或复杂计算
- 将大事务拆分为多个小事务
合理设置隔离级别：
- 不要盲目使用最高隔离级别（串行化）
- 对于只读操作，可以使用 read only 事务减少锁的使用
优化数据访问模式：
- 按照相同的顺序访问表和行，减少死锁
- 避免事务中对大量数据进行扫描和更新
定期监控和处理长事务：
- 使用 information_schema.innodb_trx 表监控长时间运行的事务
- 设置 innodb_rollback_on_timeout 参数控制超时事务的行为