一、事务 (Transaction) 的核心理解

定义：事务是数据库操作的逻辑单元，包含一个或多个 SQL 语句。这些操作要么全部成功，要么全部失败（回滚），确保数据从一种一致性状态转换到另一种一致性状态。

核心特性 (ACID)：

特性	说明	实现机制
A: 原子性	事务是最小执行单位，不可分割	Undo Log（记录修改前的值，用于回滚）
C: 一致性	事务执行前后，数据满足业务规则约束	由应用层 + 数据库约束（主键、外键等）共同保证
I: 隔离性	并发事务互相隔离，互不干扰	隔离级别 + MVCC/锁 机制
D: 持久性	事务提交后，修改永久保存	Redo Log（重做日志，崩溃恢复）

二、事务隔离级别 (Isolation Levels)

隔离级别解决并发事务引发的数据一致性问题。级别越高，一致性越强，并发性能越低。

四大并发问题

1. 脏读 (Dirty Read)：事务 A 读到事务 B未提交的修改。

2. 不可重复读 (Non-Repeatable Read)：事务 A 多次读取同一数据，事务 B 在期间修改并提交，导致 A 读取结果不一致。

3. 幻读 (Phantom Read)：事务 A 多次查询同一条件，事务 B 在期间新增/删除符合条件的数据并提交，导致 A 结果集变化。

4. 丢失更新 (Lost Update)：两个事务同时修改同一数据，后提交的覆盖先提交的结果（可通过锁避免）。

---

四种隔离级别详解

隔离级别	脏读	不可重复读	幻读	实现方式（MySQL InnoDB）	适用场景
READ UNCOMMITTED	❌	❌	❌	不加锁，直接读最新数据	极少使用
READ COMMITTED (RC)	✅	❌	❌	MVCC：每次读创建新快照	高并发读，接受不可重复读（如统计日志）
REPEATABLE READ (RR)	✅	✅	⚠️*	MVCC：事务首次读创建快照 + Next-Key Locks	MySQL 默认级别，平衡一致性与性能
SERIALIZABLE	✅	✅	✅	完全串行执行（加读锁）	强一致性，低并发场景（如金融交易）

⚠️ 注意：

• MySQL 的 REPEATABLE READ 通过 Next-Key Lock 解决了幻读（通过锁住范围阻止其他事务插入）。

• "不可重复读" vs "幻读"：前者针对已存在数据的修改，后者针对数据行的增删。

三、后端开发中的实践要点

1. 默认级别选择：

   • MySQL 默认 RR，PostgreSQL 默认 RC。

   • RC 比 RR 锁竞争少，并发度更高，适合读多写少场景。

   • RR 适合需要事务内多次读取一致的场景（如账户余额校验）。

2. 显式控制事务：

START TRANSACTION;
-- SQL操作...
COMMIT; -- 或 ROLLBACK;

3. 避免长事务：

   • 长事务占用锁资源，导致并发瓶颈。

   • 监控手段：SHOW ENGINE INNODB STATUS 查看事务锁信息。

4. MVCC (多版本并发控制)：

   • InnoDB 通过 Undo Log 构建数据历史版本，实现无锁读。

   • 每个事务有唯一 事务ID，快照读基于此 ID 判断数据可见性。

---

四、面试高频问题与回答

1. ACID 是什么？如何实现？

   • 原子性 → Undo Log；持久性 → Redo Log；隔离性 → 锁 + MVCC；一致性 → 前三者共同保证。

2. RR 级别如何解决幻读？

   通过 Next-Key Lock（行锁 + 间隙锁）锁定查询范围，阻止其他事务插入符合条件的数据。

3. RC 和 RR 的主要区别？

   • RC：每次读生成新快照，可能不可重复读，但锁冲突少。

   • RR：事务首次读生成快照，全程使用同一快照，通过锁避免幻读。

4. 什么场景下选 SERIALIZABLE？

   强一致性要求极高（如银行转账），且并发量低的场景。一般优先用 RR + 乐观锁。

5. MVCC 原理？

   每个数据行有隐藏字段 DB_TRX_ID（最后修改的事务 ID）和 DB_ROLL_PTR（指向 Undo Log 的指针）。读操作根据事务 ID 和快照决定可见版本。

总结

维度	关键点
事务本质	ACID 特性保证数据一致性
隔离级别	从 READ UNCOMMITTED 到 SERIALIZABLE，隔离性增强，并发性下降
MySQL 实现	默认 RR，通过 MVCC + Next-Key Lock 高效解决幻读
开发建议	优先用默认 RR；读多写少场景可考虑 RC；避免长事务

---

事务定义

• 事务（Transaction）：一个最小的不可再分的工作单元；通常一个事务对应一个完整的业务(例如银行账户转账业务，该业务就是一个最小的工作单元)

• 一个完整的业务需要批量的 DML(insert、update、delete)语句共同联合完成；

• 事务只和 DML 语句有关，或者说 DML 语句才有事务。这个和业务逻辑有关，业务逻辑不同，DML 语句的个数不同

• 在 MySQL 中只有使用了 Innodb 数据库引擎的数据库或表才支持事务。

一个数据库事务通常包含对数据库进行读或写的一个操作序列。它的存在包含有以下两个目的：

1. 为数据库操作提供了一个从失败中恢复到正常状态的方法，同时提供了数据库即使在异常状态下仍能保持一致性的方法。
2. 当多个应用程序在并发访问数据库时，可以在这些应用程序之间提供一个隔离方法，以防止彼此的操作互相干扰。

当一个事务被提交给了 DBMS（数据库管理系统），则 DBMS 需要确保该事务中的所有操作都成功完成且其结果被永久保存在数据库中，如果事务中有的操作没有成功完成，则事务中的所有操作都需要被回滚，回到事务执行前的状态（要么全执行，要么全都不执行）；同时，该事务对数据库或者其他事务的执行无影响，所有的事务都好像在独立的运行。

但在现实情况下，失败的风险很高。在一个数据库事务的执行过程中，有可能会遇上事务操作失败、数据库系统/操作系统失败，甚至是存储介质失败等情况。这便需要 DBMS 对一个执行失败的事务执行恢复操作，将其数据库状态恢复到一致状态（数据的一致性得到保证的状态）。为了实现将数据库状态恢复到一致状态的功能，DBMS 通常需要维护事务日志以追踪事务中所有影响数据库数据的操作。

示例

关于银行账户转账操作，账户转账是一个完整的业务，最小的单元，不可再分——也就是说银行账户转账是一个事务

以下是银行账户表 t_act(账号、余额)，进行转账操作：

    actno       balance
    1           500
    2           100

转账操作

    update t_act set balance=400 where actno=1;
    update t_act set balance=200 where actno=2;

以上两条 DML 语句必须同时成功或者同时失败。最小单元不可再分，当第一条 DML 语句执行成功后，并不能将底层数据库中的第一个账户的数据修改，只是将操作记录了一下；这个记录是在内存中完成的；当第二条 DML 语句执行成功后，和底层数据库文件中的数据完成同步。若第二条 DML 语句执行失败，则清空所有的历史操作记录，要完成以上的功能必须借助事务

四大特征(ACID)

• 原子性(Atomicity)：事务是最小单位，不可再分
• 一致性(Consistency)：事务要求所有的 DML 语句操作的时候，必须保证同时成功或者同时失败
• 隔离性(Isolation)：事务 A 和事务 B 之间具有隔离性，一个事务的执行不应影响其他事务的执行。
• 持久性(Durability)：是事务的保证，事务终结的标志(内存的数据持久到硬盘文件中)

控制语句

• 开启事务：Start Transaction/ BEGIN
• 事务结束：End Transaction
• 提交事务：Commit Transaction
• 回滚事务：Rollback Transaction

---

• BEGIN 或 START TRANSACTION 显式地开启一个事务；
• COMMIT 也可以使用 COMMIT WORK，不过二者是等价的。COMMIT 会提交事务，并使已对数据库进行的所有修改成为永久性的；
• ROLLBACK 也可以使用 ROLLBACK WORK，不过二者是等价的。回滚会结束用户的事务，并撤销正在进行的所有未提交的修改；
• SAVEPOINT identifier，SAVEPOINT 允许在事务中创建一个保存点，一个事务中可以有多个 SAVEPOINT；
• RELEASE SAVEPOINT identifier 删除一个事务的保存点，当没有指定的保存点时，执行该语句会抛出一个异常；
• ROLLBACK TO identifier 把事务回滚到标记点；
• SET TRANSACTION 用来设置事务的隔离级别。InnoDB 存储引擎提供事务的隔离级别有 READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ 和 SERIALIZABLE。

代码示例

mysql> use RUNOOB;
Database changed
mysql> CREATE TABLE runoob_transaction_test( id int(5)) engine=innodb;  # 创建数据表
Query OK, 0 rows affected (0.04 sec)
 
mysql> select * from runoob_transaction_test;
Empty set (0.01 sec)
 
mysql> begin;  # 开始事务
Query OK, 0 rows affected (0.00 sec)
 
mysql> insert into runoob_transaction_test value(5);
Query OK, 1 rows affected (0.01 sec)
 
mysql> insert into runoob_transaction_test value(6);
Query OK, 1 rows affected (0.00 sec)
 
mysql> commit; # 提交事务
Query OK, 0 rows affected (0.01 sec)
 
mysql>  select * from runoob_transaction_test;
+------+
| id   |
+------+
| 5    |
| 6    |
+------+
2 rows in set (0.01 sec)
 
mysql> begin;    # 开始事务
Query OK, 0 rows affected (0.00 sec)
 
mysql>  insert into runoob_transaction_test values(7);
Query OK, 1 rows affected (0.00 sec)
 
mysql> rollback;   # 回滚
Query OK, 0 rows affected (0.00 sec)
 
mysql>   select * from runoob_transaction_test;   # 因为回滚所以数据没有插入
+------+
| id   |
+------+
| 5    |
| 6    |
+------+
2 rows in set (0.01 sec)

和事务相关的两条重要的 SQL 语句(TCL)

• commit:提交
• rollback：回滚

事务开启的标志？事务结束的标志

开启标志

• 任何一条 DML 语句(insert、update、delete)执行，标志事务的开启

结束标志(提交或者回滚)

• 提交：成功的结束，将所有的 DML 语句操作历史记录和底层硬盘数据来一次同步
• 回滚：失败的结束，将所有的 DML 语句操作历史记录全部清空

事务与数据库底层数据

在事务进行过程中，未结束之前，DML 语句是不会更改底层数据，只是将历史操作记录一下，在内存中完成记录。只有在事务结束的时候，而且是成功的结束的时候，才会修改底层硬盘文件中的数据

在 MySQL 中，事务提交与回滚

在 MySQL 中，默认情况下，事务是自动提交的，也就是说，只要执行一条 DML 语句就开启了事务，并且提交了事务

以上的自动提交机制是可以关闭的

对t_user进行提交和回滚操作

提交操作(事务成功)

• start transaction

• DML 语句

• commit

mysql> start transaction; //手动开启事务
mysql> insert into t_user(name) values('pp');
mysql> commit; // commit之后即可改变底层数据库数据
mysql> select * from t_user;
+----+------+
| id | name |
+----+------+
|  1 | jay  |
|  2 | man  |
|  3 | pp   |
+----+------+
3 rows in set (0.00 sec)

回滚操作(事务失败)

• start transaction
• DML 语句
• rollback

mysql> start transaction;
mysql> insert into t_user(name) values('yy');
mysql> rollback;
mysql> select * from t_user;
+----+------+
| id | name |
+----+------+
|  1 | jay  |
|  2 | man  |
|  3 | pp   |
+----+------+
3 rows in set (0.00 sec)

事务四大特性之一——隔离性(isolation)

1. 隔离性有隔离级别(4 个)

   • 读未提交：read uncommitted
   • 读已提交：read committed
   • 可重复读：repeatable read
   • 串行化：serializable 我们假设事务 A 和事务 B 之间具有一定的隔离性，下面分别讨论：

2. read uncommitted（未提交读）

   • 事务 A 和事务 B，事务 A 未提交的数据，事务 B 可以读取到
   • 这里读取到的数据叫做“脏数据”，被称为脏读（Dirty Read）
   • 这种隔离级别最低，这种级别一般是在理论上存在，数据库隔离级别一般都高于该级别

3. read committed（提交读） 这个级别是大多数数据库系统的默认隔离级别（但 MySQL 不是）。一个事务从开始直到提交之前，所做的任何修改对其他事务都是不可见的。这个级别也叫作不可重复读（nonrepeatable read），因为两次执行同样的查询，可能会得到不一样的结果。

   • 事务 A 和事务 B，事务 A 提交的数据，事务 B 才能读取到
   • 这种隔离级别高于读未提交
   • 换句话说，对方事务提交之后的数据，我当前事务才能读取到
   • 这种级别可以避免“脏数据”
   • 这种隔离级别会导致“不可重复读取”
   • Oracle 默认隔离级别

4. repeatable read（可重复读） 该级别保证了在同一个事务中多次读取同样记录的结果是一致的，但依然无法解决另外一个幻读（Phantom Read）的问题。幻读，指的是当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，会产生幻行（Phantom Row）。InnoDB 和 XtraDB 存储引擎通过多版本并发控制（MVCC）解决了幻读的问题。可重复读是 MySQL 的默认事务隔离级别。

   • 事务 A 和事务 B，事务 A 提交之后的数据，事务 B 读取不到
   • 事务 B 是可重复读取数据
   • 这种隔离级别高于读已提交
   • 换句话说，对方提交之后的数据，我还是读取不到
   • 这种隔离级别可以避免“不可重复读取”，达到可重复读取
   • 比如 1 点和 2 点读到数据是同一个
   • MySQL 默认级别
   • 虽然可以达到可重复读取，但是会导致“幻像读”

5. serializable（可串行化） 最高的隔离级别，强制事务串行执行，避免了前面说的幻读的问题。但每次读都需要获得表级共享锁，读写相互都会阻塞。

• 事务 A 和事务 B，事务 A 在操作数据库时，事务 B 只能排队等待
• 这种隔离级别很少使用，吞吐量太低，用户体验差
• 这种级别可以避免“幻像读”，每一次读取的都是数据库中真实存在数据，事务 A 与事务 B 串行，而不并发

隔离级别与一致性关系

事务隔离级别	脏读	可重复读	幻读
未提交读（read uncommited）	×	×	×
提交读（read commited）	√	×	×
可重复读（repeatable read）	√	√	×
串行化（serialziable)	√	√	√

注：×表示有该问题，√表示解决该问题。

1. 脏读：事务 A 读取了事务 B 更新的数据，然后 B 进行回滚操作，那么 A 读取到的数据是脏数据；

2. 不可重复读：事务 A 多次读取同一数据，事务 B 在事务 A 多次读取的过程中，对数据作了更新并提交，导致事务 A 多次读取同一数据时，结果不一致;

3. 幻读：事务 A 按照一定条件进行范围内的记录数据读取，期间事务 B 插入了相同搜索条件的新数据，事务 A 再次按照原先条件进行读取时，发现了事务 B 新插入的数据，这就是幻读；

隔离级别越高，越能保证数据的完整性和统一性，但是对并发性能的影响也越大。对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为 Read Committed。它能够避免脏读，而且具有较好的并发性能。尽管它会导致不可重复读、幻读和第二类丢失更新这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。

• MySQL 事务隔离机制&锁 (opens new window)
• MySQL 隔离级别 (opens new window)
• 数据库事务和四种隔离级别 (opens new window)
• RR(REPEATABLE-READ) 与 RC(READ-COMMITED) 隔离级别的异同 (opens new window)

设置事务隔离级别

方式一

• 可以在 my.ini 文件中使用 transaction-isolation 选项来设置服务器的缺省事务隔离级别。

• 该选项值可以是：

– READ-UNCOMMITTED
– READ-COMMITTED
– REPEATABLE-READ
– SERIALIZABLE

例如

[mysqld]
transaction-isolation = READ-COMMITTED

方式二

• 通过命令动态设置隔离级别

隔离级别也可以在运行的服务器中动态设置，应使用 SET TRANSACTION ISOLATION LEVEL 语句。
其语法模式为：

SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL <isolation-level>

其中的<isolation-level>可以是：

– READ UNCOMMITTED
– READ COMMITTED
– REPEATABLE READ
– SERIALIZABLE

例如： SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

隔离级别的作用范围

事务隔离级别的作用范围分为两种： – 全局级：对所有的会话有效 – 会话级：只对当前的会话有效 例如，设置会话级隔离级别为 READ COMMITTED ：

mysql> SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

或：

mysql> SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

设置全局级隔离级别为READ COMMITTED：

mysql> SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;

查看隔离级别

事务隔离级别的作用范围分为两种： – 全局级：对所有的会话有效 – 会话级：只对当前的会话有效 例如，设置会话级隔离级别为READ COMMITTED：

mysql> SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

或：

mysql> SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

设置全局级隔离级别为 READ COMMITTED ：

mysql> SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;

参考来源

• MySQL——事务(Transaction)详解_浅然的专栏-CSDN 博客 (opens new window)
• MySQL 事务 | 菜鸟教程 (opens new window)
• 彻底理解数据库事务-HollisChuang's Blog (opens new window)