MySQL 事务与隔离级别：从 ACID 到 MVCC 原理

小飞兽 MySQL 5 次阅读 2026-07-29

前言

事务是数据库一致性的保障，理解和正确使用事务隔离级别，是避免并发数据问题的关键。在实际开发中，脏读、不可重复读、幻读这些问题如果不加控制，轻则导致数据不一致，重则引发严重的业务 Bug。本文将带你深入理解 MySQL 事务的 ACID 特性、四种隔离级别以及 MVCC 的实现原理。

ACID 四大特性

事务必须满足 ACID 四大特性，这是数据库理论的基础：

Atomicity（原子性）：事务是最小执行单元，一个事务中的所有操作要么全部成功，要么全部失败回滚，不存在中间状态。InnoDB 通过 Undo Log 实现事务回滚。

Consistency（一致性）：事务执行前后，数据库的完整性约束保持一致（如主键唯一、外键约束等）。一致性是最终目标，由应用层和数据库共同保证。

Isolation（隔离性）：并发执行的事务相互隔离，互不干扰。隔离级别决定了并发事务之间能看到彼此多少数据。

Durability（持久性）：事务提交后，其结果永久保存。即使发生系统崩溃，数据也不会丢失。InnoDB 通过 Redo Log（Write-Ahead Logging）保证持久性。

四种隔离级别

SQL 标准定义了四种事务隔离级别，从低到高如下：

| 隔离级别 | 脏读 | 不可重复读 | 幻读 |
|---------|------|-----------|------|
| READ UNCOMMITTED | 可能 | 可能 | 可能 |
| READ COMMITTED | 不可能 | 可能 | 可能 |
| REPEATABLE READ（默认） | 不可能 | 不可能 | 可能 |
| SERIALIZABLE | 不可能 | 不可能 | 不可能 |

-- 查看当前会话隔离级别
SELECT @@transaction_isolation;

-- 设置隔离级别（会话级）
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

-- 开启事务的标准方式
START TRANSACTION;

-- 提交事务
COMMIT;

-- 回滚事务
ROLLBACK;

-- 设置事务自动提交（MySQL 默认开启）
SET autocommit = 1;  -- 1=自动提交，0=手动提交

并发问题详解

脏读（Dirty Read）：一个事务读取了另一个事务未提交的数据。如果那个事务最终回滚，读取的数据就是无效的。

不可重复读（Non-repeatable Read）：同一事务中，两次读取同一行数据得到不同结果（因为其他事务修改并提交了这条数据）。

幻读（Phantom Read）：同一事务中，两次执行相同查询，得到不同的行集合（因为其他事务插入了新行）。

READ COMMITTED 与 REPEATABLE READ 的区别

这是 MySQL 中最常用的两个隔离级别，其核心差异在于快照的创建时机：

READ COMMITTED（RC）：每次读取数据时都生成一个新的快照。可以读到已提交的最新数据，但同一事务中两次读取同一行可能得到不同值。

REPEATABLE READ（RR）：事务开始时生成一个快照，整个事务期间都读这个快照中的数据。保证同一事务中多次读取结果完全一致。

-- 演示不可重复读（RC 级别）
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION;
SELECT balance FROM accounts WHERE user_id = 1;  -- 结果：10000
-- 在另一个会话中：UPDATE accounts SET balance = 9000 WHERE user_id = 1; COMMIT;
SELECT balance FROM accounts WHERE user_id = 1;  -- 结果：9000（不可重复读）
COMMIT;

-- 演示 RR 级别（避免不可重复读）
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION;
SELECT balance FROM accounts WHERE user_id = 1;  -- 结果：10000（快照版本）
-- 在另一个会话中：UPDATE accounts SET balance = 9000 WHERE user_id = 1; COMMIT;
SELECT balance FROM accounts WHERE user_id = 1;  -- 仍然是 10000
COMMIT;

MVCC 原理详解

MySQL 的 InnoDB 引擎使用 MVCC（Multi-Version Concurrency Control，多版本并发控制）来实现非阻塞读操作。MVCC 的核心思想是为每个读操作创建一个时间点快照，使得读写操作互不阻塞。

隐藏列：InnoDB 为每一行数据添加了两个隐藏列：

<code>DB_TRX_ID</code>：最近一次修改该行的事务 ID

<code>DB_ROLL_PTR</code>：指向 Undo Log 中旧版本数据的指针

Undo Log 链：当一行数据被更新时，InnoDB 将旧数据写入 Undo Log，并通过 DB_ROLL_PTR 形成一条版本链。通过这条链，可以追溯到任意历史版本。

-- InnoDB 事务 ID 分配（可见性判断的核心）
SELECT trx_id, trx_state, trx_started FROM information_schema.INNODB_TRX;

-- 查看行数据的隐藏列
SELECT * FROM performance_schema.events_transactions_current;

-- MVCC 快照的可见性判断规则（Read View）：
-- 1. 如果数据的 trx_id < min_trx_id，表示该数据在事务开始前已提交，可见
-- 2. 如果数据的 trx_id = 当前事务ID，表示是自己修改的，可见
-- 3. 如果数据的 trx_id > min_trx_id 且不在活跃事务列表中，表示事务已提交，可见
-- 4. 否则，表示数据被一个未提交事务修改，不可见（沿 Undo Log 链向上查找）

快照读与当前读：

快照读（Snapshot Read）：普通 SELECT 语句，使用 MVCC 读取历史快照，不加锁。

当前读（Current Read）：SELECT ... FOR UPDATE、INSERT、UPDATE、DELETE 语句，读取最新提交的数据，并对读取的行加锁。

-- 快照读（不加锁，使用 MVCC）
SELECT * FROM accounts WHERE user_id = 1;  -- 读快照

-- 当前读（加锁读取最新数据）
SELECT * FROM accounts WHERE user_id = 1 FOR UPDATE;
INSERT INTO orders (...) VALUES (...);
UPDATE accounts SET balance = balance - 100 WHERE user_id = 1;

Next-Key Lock 与幻读解决

MySQL 的 REPEATABLE READ 隔离级别通过 Next-Key Lock 算法解决了幻读问题。

Next-Key Lock 是记录锁（Record Lock）和间隙锁（Gap Lock）的组合：

记录锁：锁定索引中存在的具体记录

间隙锁：锁定两条记录之间的间隙，防止新记录插入

-- REPEATABLE READ 下执行范围查询
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION;

-- 这个查询会对 age > 20 的范围加 Next-Key Lock
-- 阻止其他事务在（20, +inf）范围内插入新记录
SELECT * FROM users WHERE age > 20 FOR UPDATE;

-- 在另一会话中，以下插入会被阻塞（直到当前事务提交）
-- INSERT INTO users (name, age) VALUES ('新用户', 25);

COMMIT;  -- 提交后，间隙锁释放，插入才能成功

常见问题

Q1：隔离级别越高性能越差吗？
是的，通常隔离级别越高，需要维护更多的锁和版本数据，并发性能会有所下降。REPEATABLE READ 是 MySQL InnoDB 的默认级别，对大多数业务场景已经足够。除非有特殊需求（如金融级严格一致性），不必过度追求 SERIALIZABLE。

Q2：长事务有什么危害？
长事务会持有大量 Read View，导致 undo log 无法回收，同时持有大量行锁或表锁，阻塞其他读写操作。应尽量将事务拆小，避免在事务中执行网络请求或复杂计算。

Q3：RR 级别下是否完全不会出现幻读？
在纯快照读（普通 SELECT）的场景下，RR 级别通过 MVCC 避免了幻读。但在当前读（SELECT ... FOR UPDATE）的场景下，虽然 Next-Key Lock 防止了新记录插入，但极端并发情况下仍可能触发幻读。对于需要强一致性的场景，应配合 SELECT ... FOR UPDATE 使用。