MySQL事务机制全解析：从ACID到MVCC与锁的实战

你是不是也有过这种经历：代码里明明写了事务，但某条 SQL 报错被 try-catch 吞掉后，数据照样被改了；或者同一个事务里两次查询同一个范围，结果却不一样；再或者线上一条 update 久久不返回，最后发现整个表的写入都被堵死了。这些问题看着五花八门，最后查来查去都会落到同一个地方——你对 MySQL 事务的理解，是不是还停留在“begin、commit、rollback 三步走”的层面。MySQL 事务听起来是入门知识，但 ACID 原则怎么落地、四种事务隔离级别有什么区别、InnoDB 底层靠什么机制扛住并发和崩溃恢复，这些才是真正决定你能不能把事务用得明白的分水岭。这篇就把事务机制从头到尾拆一遍，结合实测验证和踩坑经验，适合准备面试的人，也适合在线上被锁问题、数据不一致问题折磨过的人。

1. 为什么说只记住 begin/commit/rollback 根本不够

1.1 一次数据更新事故：事务边界比想象中宽

先讲一个我早年间遇到的实际问题。有个订单结算功能，逻辑是先把订单状态从“待结算”改成“结算中”，然后扣减库存，最后写一条流水。代码里确实开了事务，三条 SQL 顺序执行，看起来没什么问题。结果上线没多久，就出现了一批订单状态是“结算中”但库存没扣、流水也没写的脏数据。

排查到最后，原因特别简单：扣库存那一步抛了一个业务异常，被 catch 住之后虽然打了日志，但事务没有回滚，直接走到了方法末尾。如果用的是 Spring 的声明式事务，事务拦截器默认会在抛出 RuntimeException 时回滚，但 checked exception 不会触发回滚。更常见的情况是很多同学习惯在 catch 块里自己处理掉异常，事务就不知道该不该回滚了。

这个案例说明一个核心认知：事务的边界不是“从 begin 到 commit”，而是“你要保证原子性的那组操作的全部范围”。一条 SQL 自动提交、多条 SQL 手动提交、异常路径怎么处理，这些都属于事务边界的范畴。如果对事务的理解只到 API 层，遇到这种问题就很容易两眼一抹黑。

1.2 InnoDB 眼中的事务生命周期

从用户视角看，事务就是 begin、写几条 SQL、commit 或 rollback。但站在 InnoDB 内部，事务的生命周期要复杂得多：

1. 客户端执行 START TRANSACTION 或 BEGIN，InnoDB 在内存里创建一个事务对象，但此时它还是个“轻量”状态，并不急着分配事务 ID。
2. 执行第一条写操作时，事务才真正获得一个自增的 trx_id，同时开始写 undo log，记录修改前的版本。
3. 修改的数据页会先被加载到缓冲池（Buffer Pool）里，在内存中完成修改，对应的 redo log 会记录这次物理修改。
4. 执行 COMMIT 时，InnoDB 要把这个事务产生的 redo log 刷到磁盘，确保数据不会丢；随后释放事务持有的锁，标记事务结束。
5. 执行 ROLLBACK 时，InnoDB 根据 undo log 把已做的修改全部还原，同样释放锁。

这里有个容易被忽略的点：事务 ID 是延迟分配的。只读事务在 MySQL 8.0 里可能根本不分配 trx_id，这直接影响后面要讲的 MVCC 可见性判断。也就是说，一个事务到底“有多老”，取决于它第一次写操作的时间，而不是打开事务的时间。

注意：BEGIN 和 START TRANSACTION 在 MySQL 里基本等价，都不会立刻建立一致性快照。真正能立刻建立快照的是 START TRANSACTION WITH CONSISTENT SNAPSHOT，这个细节后面讲 MVCC 时再展开。

2. ACID 不是口号：InnoDB 底层靠什么硬扛

ACID 四个字母每个人都背得出来，但面试时追问一句“原子性靠什么实现、持久性靠什么实现”，能答全的人不多。这里把四个特性和 InnoDB 的底层机制逐一对应起来。

2.1 持久性：WAL 与 redo log 的刷盘时机

先想一个问题：如果每次修改数据都直接改磁盘上的数据页，性能会是灾难。因为数据页默认 16KB，一次 update 哪怕只改了一个字段，也得把这个页读出来、改完、写回去。而且数据页在磁盘上是随机分布的，随机 IO 的速度比顺序 IO 慢几个数量级。InnoDB 的解法是 WAL（Write-Ahead Logging，预写日志）：先写日志，再写数据页。

redo log 记录的是“物理级别”的修改，比如“在表空间 X 的第 Y 页偏移量 Z 处写入了什么”。它追加写入磁盘，是顺序 IO，速度很快。事务提交时，只要 redo log 落盘了，即使数据页还没来得及刷到磁盘，MySQL 崩溃了也能在恢复时通过 redo log 重放修改，这就是持久性的来源。

这里有个关键参数 innodb_flush_log_at_trx_commit，三个取值对应三种权衡：

生产环境默认 1，这是最安全的选择。如果对性能极度敏感且能接受丢失最后 1 秒事务，可以考虑 2。另外 InnoDB 还有组提交（group commit）机制，多个事务提交时把 redo log 刷盘合并成一次，所以在高并发下也没有想象中那么慢。

2.2 原子性：undo log 怎么做到“后悔药”

原子性靠的是 undo log。每执行一条写操作，InnoDB 都会生成对应的 undo 记录：

• INSERT 的 undo 记录里保存了主键信息，回滚时直接删除这条记录。
• DELETE 不是物理删除，而是先把记录标记为删除，undo 里保存删除前的完整行数据，回滚时恢复。
• UPDATE 的 undo 保存修改前的旧值，回滚时用旧值覆盖新值。

这些 undo 记录会串成版本链，放在回滚段（rollback segment）里。事务执行 ROLLBACK 时，就沿着这个事务生成的 undo 记录逆向执行，把修改全部还原。

有意思的是，undo log 页面的写入本身也要记 redo log。也就是说，回滚时需要的 undo 数据，也是靠 redo log 保证不丢的。这一点很多人没意识到——原子性和持久性在底层是交织在一起的。

2.3 隔离性：锁和 MVCC 的分工

隔离性解决的是“多个事务同时操作同一批数据时，怎么互不干扰”。InnoDB 的策略是分工协作：

• 写和写冲突：用锁解决。一个事务修改了某行，另一个事务要修改同一行，必须等前一个事务提交或回滚释放锁。
• 读和写冲突：用 MVCC（多版本并发控制）解决。普通 SELECT 走快照读，读的是数据的历史版本，不需要等写事务释放锁，也不会阻塞写事务。
• 读和读冲突：不需要处理，共享读。

锁保证的是“当前读”的正确性，MVCC 保证的是“快照读”的正确性。后面第四章和第五章会分别拆开讲。

2.4 一致性：靠约束、undo log 和两阶段提交兜底

一致性不是靠某一个机制单独保证的，它是原子性、隔离性、持久性共同作用的结果，加上数据库自身的约束（主键、外键、唯一索引、非空约束）。比如转账场景，A 扣 100、B 加 100，只有这两个操作同时成功或同时失败，总金额才不会变。

这里还要提到 redo log 和 binlog 的两阶段提交。redo log 是 InnoDB 引擎层的日志，binlog 是 MySQL Server 层的日志，用于主从复制和数据恢复。事务提交时，redo log 和 binlog 都要写，如果两者不一致，崩溃恢复时就会出现主库数据与从库数据不一致的问题。

InnoDB 的做法是内部 XA 两阶段提交：

1. 事务修改数据，写 redo log，状态为 PREPARE。
2. 写 binlog，此时事务已经“板上钉钉”。
3. 将 redo log 状态改为 COMMIT，事务真正完成。

如果崩溃发生在写完 binlog 但没标记 COMMIT 时，恢复过程会以 binlog 为准，把事务补交；如果崩溃发生在写 binlog 之前，则回滚事务。这套机制保证了即使 MySQL 在提交瞬间崩溃，主从数据也不会出现“一个提交了、一个没提交”的分叉。

3. 四种隔离级别的实测：脏读、不可重复读、幻读到底怎么出现

3.1 隔离级别到底隔离了什么

SQL 标准定义了四种隔离级别，按从松到严排序：

• READ UNCOMMITTED（读未提交）：一个事务能读到另一个事务未提交的数据。
• READ COMMITTED（读已提交）：只能读到已提交的数据，解决脏读。
• REPEATABLE READ（可重复读）：同一个事务内多次读同一数据，结果保持一致，解决不可重复读。
• SERIALIZABLE（串行化）：事务完全串行执行，读写都要加锁，隔离级别最高，并发能力最差。

MySQL 默认是 REPEATABLE READ。注意，SQL 标准里 RR 是允许幻读的，但 InnoDB 通过 MVCC 和间隙锁把幻读也处理掉了，这是 InnoDB 比标准 RR 更强的地方。

3.2 实测脏读：READ UNCOMMITTED 有多危险

先建一张简单的测试表：

sql复制CREATE TABLE account (
  id INT PRIMARY KEY AUTO_INCREMENT,
  user_name VARCHAR(32) NOT NULL,
  balance DECIMAL(10,2) NOT NULL DEFAULT 0
) ENGINE=InnoDB;

INSERT INTO account(user_name, balance) VALUES ('zhangsan', 1000);

两个会话，会话 A 执行：

sql复制SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
START TRANSACTION;
UPDATE account SET balance = balance - 100 WHERE user_name = 'zhangsan';

不提交。此时会话 B 执行：

sql复制SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SELECT balance FROM account WHERE user_name = 'zhangsan';

会话 B 会读到 900。这个 900 是会话 A 还没提交的中间状态。如果会话 A 随后 ROLLBACK，那会话 B 刚才读到的 900 就是根本不存在的脏数据。

实战解读：READ UNCOMMITTED 在绝大多数业务场景下没有使用价值。除非你做的是“读个大概就行，错了也无所谓”的统计类需求，否则不要碰它。

3.3 实测不可重复读：READ COMMITTED 的典型场景

把隔离级别改成 READ COMMITTED，会话 A 开启事务并查询：

sql复制SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION;
SELECT balance FROM account WHERE user_name = 'zhangsan';

此时查到 900（假设上一步已提交）。然后会话 B 执行：

sql复制UPDATE account SET balance = balance + 50 WHERE user_name = 'zhangsan';
COMMIT;

会话 A 再次执行同一条 SELECT，查到 950。同一个事务里，同样的条件，两次查询结果不一样。这就是不可重复读。产生的原因是 RC 级别下每次 SELECT 都会生成一个新的快照，所以每次读到的都是“最新已提交版本”。

不可重复读在业务里会造成很隐蔽的问题。比如事务里先查了一遍余额，然后基于这个余额做扣减判断，中间别的会话改了余额，第二次查询就发现状况不对了。

3.4 幻读：REPEATABLE READ 为什么能压住它

幻读和不可重复读的区别在于：不可重复读是同一行数据的内容变了，幻读是查询结果的行数变了，多了一些原本不存在的数据行。

在 InnoDB 的 REPEATABLE READ 级别下，普通 SELECT 走快照读，整个事务只用一个稳定的快照，所以快照读永远不会出现幻读。比如会话 A 先执行：

sql复制SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION;
SELECT COUNT(*) FROM account WHERE balance > 100;

返回 1。会话 B 插入一条 balance=200 的记录并提交。会话 A 再次执行同样的 COUNT(*)，返回还是 1，因为读的是同一个快照。

但有一个边界情况要注意：如果事务里既有快照读，又有当前读（SELECT ... FOR UPDATE 或 UPDATE），或者第一个操作就是当前读，那么 InnoDB 靠的是 next-key lock（临键锁）来阻止其他事务在扫描区间内插入新行。这个锁同时锁住已存在的记录和记录之间的间隙，从根本上挡住幻行。所以准确说法是：快照读场景下 InnoDB 完全规避了幻读，当前读场景下借助 next-key lock 在绝大多数场景下规避了幻读，但遇到特殊的边界条件（比如唯一键冲突、锁范围没有覆盖到的分支）仍有可能出现诡异情况，这也是为什么面试官总爱追着幻读不放。

4. MVCC 与 ReadView：快照读的可见性判断逻辑

4.1 一行记录的版本链：trx_id 与 roll_pointer

MVCC 不是魔法，它依赖行记录上的两个隐藏字段：

• trx_id：最近一次修改这行数据的事务 ID。
• roll_pointer：指向该行在 undo log 中上一个版本的指针。

每次修改都会生成一个新版本，旧版本通过 roll_pointer 串成一条版本链。比如一行数据先被事务 10 插入、事务 20 修改过、事务 30 又修改过，那版本链从上到下就是 30 的版本、20 的版本、10 的版本。

快照读要判断“该读版本链上的哪个版本”，靠的是 ReadView（读视图）。ReadView 里有四个关键信息：

• m_ids：生成 ReadView 时当前系统中所有活跃（未提交）事务的 ID 集合。
• min_trx_id：m_ids 中最小的 ID。
• max_trx_id：下一个将要分配的事务 ID，也就是当前活跃事务里最大的 ID 再加 1。
• creator_trx_id：生成这个 ReadView 的事务自己的 ID。

判断一行数据是否可见的规则可以总结成四句话：

1. 如果这行数据的 trx_id 等于 creator_trx_id，说明是自己改的，可见。
2. 如果 trx_id 小于 min_trx_id，说明这个版本在 ReadView 生成前就已经提交了，可见。
3. 如果 trx_id 大于等于 max_trx_id，说明这个版本是在 ReadView 生成之后才产生的事务改的，不可见。
4. 如果 trx_id 在 min_trx_id 和 max_trx_id 之间，需要检查它是否在 m_ids 里：在，说明还没提交，不可见；不在，说明已经提交，可见。

如果当前版本不可见，就沿着 roll_pointer 找上一个版本继续判断，直到找到可见版本或到达版本链头部。

提示：这套判断逻辑是面试高频考点。很多人背过 ReadView 四个字段，但一落到具体行的判断就乱。核心就一句：比 ReadView 早且已提交的版本可见，比 ReadView 晚或未提交的版本不可见，自己的修改始终可见。

4.2 快照生成时机：begin 不等于建立快照

很多人有一个误解：START TRANSACTION 之后，事务的快照就建好了。实际上，普通 START TRANSACTION 只是开启一个事务，ReadView 要等到第一条快照读语句执行时才生成。

而在 REPEATABLE READ 级别下，这个 ReadView 一旦生成，整个事务期间都不再变化。所以 RR 的可重复读，精确说法是“基于事务内第一个一致性快照的可重复读”。

那如果事务的第一条语句不是 SELECT，而是 UPDATE 呢？比如：

sql复制START TRANSACTION;
UPDATE account SET balance = balance + 1 WHERE id = 1;
SELECT * FROM account WHERE id = 1;

这里 UPDATE 是当前读，它在执行时加锁并读取最新版本。随后 SELECT 第一次生成 ReadView 时，这个 UPDATE 已经是“自己做的修改”了，所以 SELECT 能看到自己刚更新的结果。这里面的细节不复杂，但理解了 ReadView 的创建时机，就能解释很多“为什么我明明开了事务，却读不到别人已提交的数据”之类的困惑。

如果你需要在开启事务的瞬间就锁定一个快照，MySQL 提供了：

sql复制START TRANSACTION WITH CONSISTENT SNAPSHOT;

这条语句在执行时立即生成 ReadView。如果业务里需要多个读操作在同一个时间点上的数据保持一致，这种方式更靠谱。

4.3 快照读和当前读：MVCC 管不到的地方

再强调一遍，MVCC 只对快照读生效。普通 SELECT 是快照读，加锁的 SELECT 是当前读，UPDATE、DELETE、INSERT 也是当前读。当前读永远读最新已提交版本，并且会加锁。

这带来一个很经典的实践问题：“先查后写”在 RR 下并不安全。比如：

sql复制START TRANSACTION;
SELECT balance FROM account WHERE user_name = 'zhangsan';  -- 快照读，读到 1000
-- 另一个事务此时把 balance 改成了 500 并提交
UPDATE account SET balance = balance - 100 WHERE user_name = 'zhangsan';

这条 UPDATE 是当前读，它读到的是 500，所以最终余额变成 400，而不是按快照里的 1000 算出 900。如果你的业务逻辑是先判断余额够不够，再扣款，这个判断可能基于过期的快照数据，导致超额扣减。解决办法是直接把判断和扣减放到一条带锁的 SQL 里，或者用 SELECT ... FOR UPDATE 做当前读，锁住这行再判断。

5. 当前读与锁：从记录锁到 next-key lock 的实战

5.1 InnoDB 的锁家族：Record、Gap、Next-Key

InnoDB 的行锁分成三种形态：

• Record Lock（记录锁）：锁住索引记录本身，比如 WHERE id = 1 命中主键唯一记录时，只锁这一行。
• Gap Lock（间隙锁）：锁住一个区间，但区间里没有实际记录。它的作用是防止其他事务在这个区间插入新行。
• Next-Key Lock（临键锁）：记录锁和间隙锁的组合，锁住“从某条记录到它前面那条记录之间”的范围，是 InnoDB RR 级别默认的行锁策略。

除此之外还有一个插入意向锁（Insert Intention Lock），它比较特殊，是为了表示“事务想在某个间隙插入数据”，多个事务可以在同一个间隙持有插入意向锁而不互相冲突，但如果间隙本身有间隙锁，插入就会被阻塞。

这里要区分两个常见场景：

• 如果 WHERE 条件命中唯一索引且是等值查询，next-key lock 会退化成 Record Lock，只锁一行。
• 如果 WHERE 条件走的是普通索引或范围查询，InnoDB 会对扫描范围内所有的记录和间隙加 next-key lock。

最容易被忽略的是：如果 WHERE 条件没有索引，InnoDB 只能全表扫描，那它会对所有记录和所有间隙加锁。这在实际生产里是噩梦级别的坑。

5.2 实测：间隙锁是怎么挡住幻读的

建一张测试表：

sql复制CREATE TABLE t (
  id INT PRIMARY KEY,
  val INT,
  KEY idx_val (val)
) ENGINE=InnoDB;

INSERT INTO t VALUES (1, 1), (5, 5), (10, 10);

会话 A 执行：

sql复制START TRANSACTION;
SELECT * FROM t WHERE val BETWEEN 5 AND 20 FOR UPDATE;

这条 SQL 走的是二级索引 idx_val，扫描范围覆盖了 val=5、val=10 的记录，以及它们之间的间隙、10 之后的正无穷间隙。此时会话 B 执行：

sql复制INSERT INTO t VALUES (6, 15);

这条插入会被阻塞，因为 val=15 落在 (10, +∞) 这个间隙里，而这正是会话 A 持有的 next-key lock 覆盖的区间。会话 B 只有等会话 A 提交或回滚，才能继续。这就是间隙锁阻止幻读的直观表现。

注意：如果 val 没有索引，同样的 SELECT ... FOR UPDATE 会把整张表的所有记录和间隙都锁住。曾有人线上跑了一条不带索引条件的 UPDATE，直接把一张几百万行的表锁死，所有写入全部排队，业务彻底卡住。排查时看 SHOW ENGINE INNODB STATUS，能看到大量事务在等待同一个行锁。

5.3 死锁与锁等待排查思路

多事务持锁交叉等待就会形成死锁。InnoDB 默认开启死锁检测，发现死锁后会回滚其中一个事务，报错类似 Deadlock found when trying to get lock。

排查锁问题，我常用的几个手段：

sql复制-- 查看当前所有事务
SELECT * FROM information_schema.innodb_trx\G

-- 查看锁等待关系
SELECT * FROM information_schema.innodb_lock_waits\G

-- 查看最近的死锁日志
SHOW ENGINE INNODB STATUS\G

SHOW ENGINE INNODB STATUS 里的 LATEST DETECTED DEADLOCK 段落会给出两个事务的 SQL 和持有的锁，是分析死锁的第一手材料。看完基本能定位到是哪两条 SQL 互相等待。

实践中的防死锁手段说简单也简单：以固定顺序访问资源、保持事务短小、尽量用索引减少锁范围、避免在事务里做耗时操作。但真正要根治，必须回到锁的粒度和顺序上来。

6. 业务侧的事务陷阱：失效场景、长事务与隔离级别选型

6.1 事务失效，到底是不是 MySQL 的锅

网上搜“事务失效场景”，能搜出一堆 Spring 事务的坑。核心集中在几个点：方法不是 public、类没有被 Spring 管理、方法自调用绕过了代理、异常被 try-catch 吞掉、传播行为设置错误。这些问题的本质是“你以为开了事务，实际没开”。

从 MySQL 的视角去验证很简单，事务开启后随便执行一条 SQL，然后去看：

sql复制SELECT trx_id, trx_state, trx_started, trx_mysql_thread_id
FROM information_schema.innodb_trx;

如果这个连接确实在事务里，这里会有一条对应的记录。如果没有，说明事务根本没开启，问题大概率不在 MySQL，而在应用层的代理或事务边界上。反过来，很多时候你以为 MySQL 出了灵异问题，实际是事务比你以为的更长——比如服务调了远程接口，整个 RPC 期间事务一直开着，连接被占住不放，慢 SQL 和锁等待就是这么来的。

6.2 长事务：undo log 膨胀的隐形杀手

长事务最大的问题不是锁，而是 undo log 无法清理。MVCC 要求“比当前活跃事务更早的版本不能删”，因为那些旧版本可能还要被某个长事务的快照读到。如果一个事务长时间不提交，它持有的 ReadView 会一直阻止 purge 线程清理 undo log，导致 undo 表空间不断膨胀，查询性能也会下降，因为版本链越来越长，每次判断可见性都要沿版本链走很远。

查询哪些事务在跑：

sql复制SELECT trx_id, trx_state, trx_started, trx_mysql_thread_id,
       TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS duration_seconds
FROM information_schema.innodb_trx
WHERE trx_state = 'RUNNING';

查出 duration_seconds 特别大的，基本就是长事务。处理方式很直接：业务上控制事务时间，别在事务里做远程调用、文件读写、大循环批量更新；代码上该提交就提交，别用一个连接开事务后长时间复用不释放。监控系统里加一个针对 information_schema.innodb_trx 的巡检，能提前发现很多隐患。

6.3 隔离级别怎么选：默认 RR 不背锅

MySQL 默认 REPEATABLE READ，Oracle 默认 READ COMMITTED，很多从 Oracle 转过来的人会顺手把 MySQL 改成 RC。改之前先搞清楚业务有没有依赖可重复读。比如财务报表场景，事务里第一次查所有订单金额汇总，经过一系列计算后再查一次订单状态，如果两次结果不一致，报表就废了。这种场景就离不开 RR。而高并发互联网场景下，如果业务里全是单行读改写，没有跨多行的一致读需求，RC 确实能有更好的并发表现，因为它不需要持有 gap lock，锁冲突概率更低。

调整方法：

sql复制-- 只对当前会话生效
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

-- 对全局新连接生效
SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;

配置文件里也可以写：

ini复制[mysqld]
transaction-isolation = READ-COMMITTED

注意 SET GLOBAL 只对新连接生效，已经存在的连接不会变。改动之前评估好业务是否依赖可重复读，别只图字面上的“性能更好”。

我自己这些年最大的感受是：MySQL 事务本身并不复杂，复杂的是它和各种业务场景揉在一起后的边界问题。你只要把“这个 SQL 是快照读还是当前读”“这个事务的边界从哪开始到哪结束”“锁覆盖了哪些范围”三个问题想清楚，绝大多数数据不一致、锁等待、事务失效的问题都能在设计阶段就挡掉。最后再提醒一句，做代码评审的时候多留意事务方法里的远程调用和循环，这两样东西是长事务的主要来源，比什么隔离级别选型都致命。