写后端代码这些年，“事务”这两个字我听了不下几百遍，但真正把它从概念变成肌肉记忆，是从一次线上资损事故开始的。那次问题非常简单：两个账户之间做金额划拨，更新余额的 SQL 执行到一半，数据库连接断了，结果一方金额已经扣减、另一方还没加上。整个团队排查了一整晚，最后的修复方案不过是给这段逻辑套上一个数据库事务——但这也让我彻底看清楚了：数据库事务解决的是并发和异常场景下的数据一致性，它不是一个“锦上添花”的功能，而是很多业务系统的底线。
这篇内容我打算从最朴素的问题讲起，把事务的原理、隔离级别、底层日志机制，以及业务代码里最常见的事务坑一次说清楚。适合刚入行的开发，也适合那些“知道事务但没系统梳理过”的同事。看完之后你会发现，事务并不只是BEGIN和COMMIT两行关键字，它背后是一整套关于“怎么安全地改变数据”的设计。
1. 先搞清楚事务到底在防什么
1.1 没有事务时，一个转账都做不对
假设你要给另一个账户转 100 元，日常操作会被拆成两条 SQL：
UPDATE account SET balance = balance - 100 WHERE id = 1; UPDATE account SET balance = balance + 100 WHERE id = 2;第一条 SQL 把账户 A 的余额减掉 100，第二条把账户 B 的余额加上 100。在一个理想世界里，两条 SQL 按顺序执行，数据库永远不出错，连接永远不中断，那事务确实没多大存在感。但现实是：SQL 可能执行失败，应用正在发布重启，网络抖动让连接超时，磁盘满导致写入报错…… 只要第一条成功、第二条没成功，资金就凭空消失了。
这就是事务最核心的存在价值：把一组操作绑定成一个不可分割的整体，要么全部成功，要么全部失败。用事务包住上面两条更新之后，如果第二条失败，数据库会自动把第一条的回滚掉，账户 A 的钱不会少：
START TRANSACTION; UPDATE account SET balance = balance - 100 WHERE id = 1; UPDATE account SET balance = balance + 100 WHERE id = 2; COMMIT;你可能会想：单条 SQL 本身不就是要么成功要么失败吗？是的，但业务从来不只是单条 SQL。一个下单动作可能要写订单表、扣库存表、写流水表；一个审批动作可能要更新审批单、记录日志、通知下一节点。只要是多步写操作，就有“写到一半出事”的可能，就需要事务。
1.2 ACID 四个属性，一个一个拆
教科书里喜欢把事务的特性总结成 ACID，也就是原子性、一致性、隔离性、持久性。这四个词看着抽象，其实对应到真实场景非常具体。
原子性（Atomicity）指的是事务里的操作像一个原子一样不可再分。要么全做，要么全不做。刚才转账例子里的两条 UPDATE，在事务里就属于一个原子操作。原子性在底层主要靠 undo log 实现：事务执行过程中如果出错或者主动回滚，数据库通过 undo log 把已经修改的数据恢复原样。
一致性（Consistency）说的是事务执行前后，数据都必须满足业务规则。比如账户余额不能为负数、订单状态不能从“已支付”跳回“待支付”。这里要注意，一致性其实有一部分是业务自己保证的，数据库只能保证约束层面的“一致”，像唯一索引、外键、非空约束等。至于“转账不能转出负数”这种逻辑，如果你代码里没判断，事务并不会替你纠正。很多新手容易把一致性和原子性混在一起，实际上原子性保证“操作不中断”，一致性保证“数据不失真”。
隔离性（Isolation）针对的是并发场景：多个事务同时在跑，彼此之间不能互相干扰。但“不能干扰”到什么程度，数据库提供了不同选项，这就是后面要说的隔离级别。如果完全没有隔离性，两个事务同时改一行数据，最后结果取决于谁后提交，另一个人的更新就丢了，这在账务系统里是不可接受的。
持久性（Durability）承诺事务一旦提交，数据就不会丢，哪怕数据库立刻宕机。持久性主要靠 redo log 来保证，崩溃后数据库重启时会重放日志，把已提交但还没来得及落盘的数据恢复出来。
注意：原子性的回滚只针对事务内已经执行的 SQL。如果你在事务里发了 HTTP 请求、写了 Redis、调了消息队列，这些动作都不受数据库事务保护。事务回滚了，外呼请求已经发出去了，这种“跨系统一致性”问题事务解决不了，需要引入别的方案。
1.3 什么场景值得开事务
不是所有代码都需要事务。如果你只是查一条数据、做一次简单的单行更新，事务意义不大。但下面这些场景，我建议你务必用事务包住：
- 多表更新，比如订单主表和订单明细表必须同时写入。
- 账户类操作，余额变动、积分变动，先查后改再记录流水。
- 库存预占，下单时扣减库存，同时生成订单记录。
- 状态机流转，一个状态要经过多步骤更新，任何一步失败都要回退。
一句话总结判断标准：如果这组操作只成功了一半，数据还能见人吗？不能见人，就开事务。
2. 隔离级别：并发下的事务“视力”差异
2.1 三个并发问题怎么理解
先看一个最常见的场景：两个事务同时操作同一行数据，或者同一个范围的数据。这时如果隔离做得不够，就会出现三类经典问题。
脏读：事务 A 修改了一行数据，还没提交；事务 B 读到了这个未提交的修改。然后 A 回滚了，那 B 刚才读到的数据就是“脏数据”，是根本不存在过的数据。比如你把订单状态改成“已支付”，事务还没提交，同事的报表任务已经把“已支付”统计进去了，下一秒你回滚了，报表数据就错了。
不可重复读：事务 A 先读一次某行数据，得到值 X；事务 B 在这期间修改了这行并提交；事务 A 再读一次，得到值 Y。同一个事务里，两次读同一行结果不同。这在报表、统计类场景里非常致命——你按时间段统计金额，第一次统计和第二统计结果不同，报表就对不上账。
幻读：事务 A 查询某个范围的数据，比如“查询状态为待支付的订单”，第一次查出 10 条；事务 B 插入了一条新的待支付订单并提交；事务 A 再查一次，查出 11 条。多出来的那条就像“幻觉”一样，凭空出现。幻读和不可重复读的区别在于：不可重复读是同一行内容变了，幻读是整个集合的行数变了。
这三个问题可以放在一张表里对比：
| 问题 | 本质 | 是否读到未提交数据 | 同一行内容变化 | 查询行数变化 |
|---|---|---|---|---|
| 脏读 | 读到未提交数据 | 是 | 可能 | 可能 |
| 不可重复读 | 已提交数据被其他事务修改 | 否 | 是 | 否 |
| 幻读 | 其他事务插入新行 | 否 | 否 | 是 |
2.2 四种隔离级别选哪个
SQL 标准给出了四个隔离级别，隔离强度从低到高：
Read Uncommitted（读未提交）：允许读未提交数据，基本等于不隔离，脏读、不可重复读、幻读都可能发生。实际生产环境几乎没人用，除非你对数据准确性完全不在乎。
Read Committed（读已提交）：只能读到已提交的数据，解决了脏读。但事务 A 两次读同一行时，如果事务 B 在中间修改并提交了，A 第二次读到的值会变，所以不可重复读依然存在。这是很多数据库的默认级别，比如 PostgreSQL、Oracle。
Repeatable Read（可重复读）：保证了同一个事务内，多次读取同一行结果一致。它解决了不可重复读，但没有彻底解决幻读。MySQL 的 InnoDB 默认就是这个级别，并且通过 next-key lock 在多数场景下连幻读也一起解决了。
Serializable（串行化）：最强隔离级别，事务之间完全串行执行，读写都要加锁，并发能力极低。除非是银行对账、极度敏感的数据批处理，否则不建议线上使用。
实际项目里，Read Committed 和 Repeatable Read 是两个最常见的选项。选哪个不只看“哪个更安全”，还要看你愿不愿意为隔离付出锁和性能代价。级别越高，通常意味着并发度越低，接口延迟越容易飙上去。
2.3 隔离级别不是靠锁硬扛出来的，MVCC 才是主角
很多人以为事务隔离是靠全程加锁实现的：读数据之前锁住，读完之后解锁。如果真这样，并发性能会惨不忍睹。现代数据库普遍采用MVCC（多版本并发控制）来优化读性能。
MVCC 的思路是：同一行数据在数据库里不只有一个版本，每次更新都会生成一个新版本，旧版本保留一段时间。事务读数据时，根据自己开启事务的时间快照，选择一个“应该看到”的版本。所以读操作不会阻塞写操作，写操作也不会阻塞读操作。
举个例子，事务 A 开启后，它读某行时看到的是一份快照版本；之后事务 B 修改了这行并提交，A 再次读这行时，根据隔离级别的规则，A 可能仍然读快照里的旧版本，这就是“可重复读”能重复的原因。底层实现涉及隐藏列、版本链和 Read View 机制，这里先不展开，后文讲 undo log 时会再提到。你只需要记住一句话：MVCC 让“读”和“写”尽量并行，隔离级别只是决定了一个事务能看到历史上哪些版本。
3. 底层“记日志”机制：事务是怎么做到能回滚又能恢复的
3.1 redo log 与写入顺序
事务提交时，数据不可能立刻刷进磁盘。原因很简单：磁盘随机写入太慢，如果把每一行修改都实时刷盘，数据库性能会低到没法用。所以数据库采用了一个经典策略：先写日志，再写数据。这个策略叫 WAL，也就是 Write-Ahead Logging。
事务执行过程中，针对每一行修改，数据库会先写一条 redo log，记录“哪个页、哪个偏移量、改成了什么”。redo log 是顺序写入的，性能远高于随机写盘。事务提交时，只要 redo log 成功落盘，事务就算提交成功了，即使数据页还没写回磁盘也问题不大。万一数据库崩溃，重启时会通过 redo log 把已提交的数据恢复出来，保证持久性。
你可以把 redo log 理解为快递的“运单记录”：包裹（数据）还没送到，但运单已经登记了。只要运单在，哪怕中途车坏了，总能按运单把包裹补送。如果没有运单，丢哪件都查不出来。
3.2 undo log 与回滚
redo log 负责“向前恢复”，undo log 则负责“向后回滚”。事务执行过程中，每次修改数据前，数据库会把修改前的值记录到 undo log 里。如果事务回滚，数据库就根据 undo log 把数据倒回原来的样子。
undo log 还有一个重要用途：它保存了每一行的历史版本，MVCC 正是通过 undo log 构成的版本链，让读操作能找到符合快照条件的旧版本。可以说，没有 undo log，隔离级别里的“可重复读”就只能靠加锁硬实现，性能会完全不同。
回滚不是万能的。如果一个事务里执行了DROP TABLE这类 DDL 操作，很多数据库会隐式提交当前事务，之前的修改就无法撤销了。所以你在代码里要特别注意，不要把 DDL 和 DML 混在同一个事务里还指望回滚救你。
3.3 一条 UPDATE 语句的完整旅程
把上面两块拼起来看，一条 UPDATE 在事务里的生命周期大致是这样的：
- 事务开启，拿到一个事务 ID。
- 执行 UPDATE，数据库先加载目标行到内存缓冲池。
- 写 undo log，记录修改前的值。
- 修改内存中的数据页。
- 写 redo log，记录修改后的值和对应页信息，此时日志处于 prepare 状态。
- 事务继续执行其他 SQL，重复上述过程。
- 执行 COMMIT，redo log 进入 commit 状态并落盘。
- 事务结束，后续数据页会在合适的时机由后台线程刷入磁盘。
如果第 7 步之前任何环节出错，数据库会利用 undo log 回滚；如果第 7 步之后数据库崩溃，redo log 能保证已提交事务不丢。这套机制就是事务可靠性的地基。理解它之后，很多面试题里的“为什么事务提交这么快”“为什么数据库宕机后数据不丢”就都有了答案。
4. 业务代码里的实用事务操作与边界设计
4.1 三种常见开启方式
事务在代码里最常见的三种落地方式，我一个个说。
第一种是 SQL 层手动控制：
START TRANSACTION; -- 业务 SQL UPDATE account SET balance = balance - 100 WHERE id = 1; UPDATE account SET balance = balance + 100 WHERE id = 2; COMMIT; -- 出错时执行 ROLLBACK;这种方式适合写存储过程、脚本或者需要精细控制提交时机的场景。但要注意，START TRANSACTION之后，如果忘记COMMIT，事务会一直挂着，连接也不释放，这在连接池场景里会快速耗尽数据库连接。
第二种是应用框架注解，比如 Java 里常见的@Transactional：
@Transactional public void transfer(Long fromId, Long toId, BigDecimal amount) { accountMapper.decrease(fromId, amount); accountMapper.increase(toId, amount); }注解方式让代码看着干净，但它隐藏了大量细节。默认情况下，只有运行时异常触发回滚，受检异常不会回滚。也就是说，如果你的方法里抛出的是业务检查异常，事务可能照样提交了。很多线上数据不一致的 bug 就是这么来的。
第三种是编程式事务，手动在代码里开启、提交、回滚：
TransactionStatus status = transactionManager.getTransaction(); try { // 业务逻辑 transactionManager.commit(status); } catch (Exception e) { transactionManager.rollback(status); throw e; }这种方式最灵活，但代码侵入性也最强。简单业务用注解足够，事务边界复杂的再考虑编程式。
4.2 事务越短越好的边界原则
我在实际 code review 里见过最多的问题，不是不写事务，而是“把太多东西塞进事务”。记住几条边界原则：
第一，事务里不要做远程调用。HTTP 请求、RPC 调用、外部接口访问，这些操作的耗时不可控。事务内请求时间越长，持有的锁就越久，其他事务等待的时间就越长。假设一个事务里调了外部接口，接口超时 30 秒，这 30 秒内相关数据行全部被锁住，线上接口可能直接雪崩。正确做法是：先本地落库，提交事务，再异步发消息或调外部接口。
第二，事务里不要做大批量循环写入。比如循环 5000 次执行 UPDATE，每次都涉及锁和日志，事务整体耗时可能好几秒。更合理的做法是拆分批次，或者先预处理再批量写入，让单个事务的持锁时间尽量短。
第三，事务里不要有太重的查询。虽然 MVCC 让普通查询不加锁，但如果你在事务里用了SELECT ... FOR UPDATE这种加锁读，或者查询本身特别慢，锁的持有时间同样会被拖长。事务不是不能查询，而是不要做与分析业务无关的重查询。
4.3 事务传播行为与嵌套问题
框架类事务通常还提供“传播行为”，简单说就是当多个事务方法嵌套调用时，是共用同一个事务，还是各开各的事务。常见的有 REQUIRED、REQUIRES_NEW、NESTED 等。
REQUIRED 是默认行为：如果外层已经有事务，内层方法直接加入外层事务，内层抛异常会导致整个外层事务回滚。REQUIRES_NEW 则是内层方法强制新开一个独立事务，外层事务跟它互不干扰，适合“日志记录”这种不管主流程成败都要落库的场景。NESTED 是嵌套事务，内层可以部分回滚，但外层整体状态仍然参与全局提交或回滚。
一个非常经典的坑是自调用失效。同一个类里的方法 A 调方法 B，B 上有事务注解，但 A 没有，此时 B 的事务可能根本不生效。原因很简单：事务是通过代理对象拦截的，类内部this调用不会走代理。很多同事排查半天，最后发现是自调用问题。解决办法是把 B 拆到另一个类，或者注入自身代理调用，再或者用编程式事务兜底。
5. 线上问题排查实录与常见坑
5.1 死锁：两个事务互相等锁
死锁是事务并发里最典型的“交通事故”。举一个最简单的例子：事务 A 更新了 id=1 的行，事务 B 更新了 id=2 的行；接着 A 想更新 id=2，B 想更新 id=1。两边都在等对方释放锁，谁都不肯放手，数据库只能靠死锁检测机制选择牺牲一个事务，让它回滚并报错。
排查死锁时，我一般先看数据库的锁等待日志。以 MySQL 为例，执行SHOW ENGINE INNODB STATUS可以看到最近一次死锁涉及的事务、执行的 SQL、等待的锁对象。看到日志后，优化思路通常是：
- 让所有事务按相同顺序访问资源，比如更新多行时先按主键排序。
- 缩小事务范围，减少持有锁的时间。
- 避免事务里做太多无关操作。
- 合理使用索引，让锁落在尽量少的行上。
如果你发现某个接口频繁报死锁，先不要急着加锁或换隔离级别，先看 SQL 的执行计划，很多时候是没走索引导致锁了全表。
5.2 长事务：连接池耗尽和 undo 膨胀
长事务是指“长时间不提交也不回滚”的事务。它的危害有两层：一是长期持有锁，阻塞其他事务；二是不停产生 undo log，导致历史版本堆积，数据库文件膨胀，查询性能下降。
有一次排查线上接口变慢，我查了information_schema.innodb_trx，发现有事务跑了将近 40 分钟还没提交。顺着线索找到代码，发现是一位同事在事务里调了外部接口，外部接口超时 30 分钟，事务就一直挂着。处理办法很简单：把外部调用移出事务，事务体只保留纯数据库操作。
监控长事务时，可以定期执行类似下面的查询，找出长时间未提交的事务：
SELECT trx_id, trx_state, trx_started, trx_rows_locked FROM information_schema.innodb_trx WHERE trx_state = 'RUNNING';看到trx_started距离当前时间超过阈值，就该告警了。另外连接池耗尽很多时候也是长事务引起的：连接被事务占住不放，新的请求拿不到连接，接口全部排队。
5.3 快照读与当前读不一致
这是 Repeatable Read 级别下一个非常隐蔽的问题。同一个事务里，普通SELECT是快照读，读到的是事务开启那一刻的快照；而UPDATE、DELETE、SELECT ... FOR UPDATE是当前读，读取的是最新已提交数据。两者混用时，可能出现“先查询到旧数据，再更新时却基于新数据计算”的诡异现象。
举个实际例子：事务里先SELECT balance拿到 100，然后执行UPDATE ... SET balance = balance - 50。这个 UPDATE 内部读到的 balance 可能是别人已经改过的 200，最终算出 150，和你期望的 50 完全不同。这类问题很难靠直觉发现，建议在设计事务逻辑时，明确自己用的是快照读还是当前读，需要严格基于最新值计算时，就直接用SELECT ... FOR UPDATE加锁读，不要依赖“查一次再改一次”的默认行为。
5.4 事务问题速查表
| 症状 | 可能原因 | 排查方法 | 处理建议 |
|---|---|---|---|
| 数据更新丢失 | 事务隔离级别过低或没有加锁 | 检查隔离级别和 SQL 加锁情况 | 提高隔离级别或使用SELECT ... FOR UPDATE |
| 接口报死锁 | 多个事务锁顺序不一致 | SHOW ENGINE INNODB STATUS查看死锁日志 | 统一资源访问顺序，缩小事务范围 |
| 连接池被占满 | 长事务未提交 | 查询information_schema.innodb_trx | 找到长事务对应的代码，移除外呼操作 |
| 事务回滚没生效 | 异常类型不被事务管理器捕获 | 确认异常是否为运行时异常，检查@Transactional配置 | 显式指定回滚异常类型 |
| 数据变了但日志没记录 | 事务提交后外呼失败 | 查看应用日志中提交顺序 | 将外呼改为事务后异步发送 |
6. 我最后想说的几句实在话
带过这么多项目，也帮同事处理过不少事务问题，我最大的体会是：事务本身不难，难的是控制事务的边界。很多人写代码时只想着“这里要加事务”，却很少想“这个事务应该多短、该不该包住这段外呼、回滚发生时旁边那些状态怎么办”。数据库事务是个好工具，但它不是万能的，更不是业务一致性的唯一保障。
我还想多说一句：事务的隔离级别、锁机制这些内容，看起来像是 DBA 才需要研究的，但作为开发，只要你的代码里有并发写操作，这些知识迟早会找上你。与其等线上出了资损、死锁、丢数据再回头补课，不如趁早把事务的底层逻辑吃透。
最后分享一个小习惯：每写一段涉及事务的代码，我都会问自己三个问题——这个事务最短能缩到多短？如果它回滚了，哪些数据会受影响？如果它成功了但旁边系统失败，数据还能不能对得上？把这三个问题想清楚，你就已经超过大多数“只会写 BEGIN”的同事了。
