尧图网站建设 
先说一句掏心窝的话在数据库系统里并发下的数据一致性永远是最让人头疼的问题。无论是订单、库存还是支付几乎每个核心业务都依赖 MySQL 事务这张安全网但真正深入使用几年后你会发现难的不是背出 ACID 那四个字母而是在 Spring 项目里把每一条 Transactional 都写对、让它真的生效。这篇文章按照“底层原理 → 隔离机制 → Spring 实现 → 失效场景 → 排查技巧 → 架构设计”的顺序把 MySQL 事务从理论到实战完整串一遍重点给你讲透 2026 年面试和线上故障里最高频的 Spring 事务失效场景适合刚接触事务的后端开发也适合准备做一次系统性复盘的老手。1. 从 ACID 到 MySQL 底层机制事务为什么是数据一致性的地基1.1 一次扣库存事故告诉我们什么前年我在处理一个“订单与库存”联调项目时同事发现库存明明是扣减成功的但订单表里查不到记录最后盘库怎么都对不上。排查后确认扣库存和建订单是两个操作分别开了两个数据库连接第一个提交成功了第二个抛异常了但因为两者之间没有公共事务边界数据一致性当场崩塌。这个场景其实特别典型。你写业务代码的时候脑子里想的是“扣库存、建订单、更新用户账单”这一整串动作应该是一个整体但数据库看到的却是一个又一个独立连接。没有事务任何一步失败都会把系统推入中间状态要么库存少了订单没产生要么钱扣了库存没减。所以事务的本质不是“更快”或“更好用”而是给一组逻辑上不可分割的操作提供一个明确的边界边界内要么全部成功要么全部回滚。1.2 ACID 四属性缺一不可ACID 是事务的四个核心属性原子性、一致性、隔离性、持久性。这些年我面试过不少候选人大部分能背出这四个词但问到一个具体业务怎么回滚、日志怎么保证崩溃恢复就卡住了。原子性Atomicity事务里的操作像一个不可分割的原子要么全部提交要么全部回滚。数据库通过 undo log 实现这一点后面会展开。一致性Consistency事务执行前后数据库始终处于合法状态。这包含数据库层面的约束也包含业务层面的规则。一致性其实是 ACID 的“目的”其他三个属性都是为它服务的。隔离性Isolation多个事务并发执行时一个事务不会被其他事务的中间状态干扰。隔离性并不是“绝对隔离”而是通过隔离级别来定义干扰程度。持久性Durability事务一旦提交修改就永久保存哪怕系统崩溃、断电也不会丢失。这四个属性不是平等的并列关系。一致性是目标原子性、隔离性、持久性是手段。你没法单独牺牲某一个来换取其他因为最终都是为了不让数据“看起来没问题但实际烂掉”。1.3 InnoDB 的两大利器redo log 与 undo logMySQL 默认的存储引擎是 InnoDB它实现 ACID 主要靠两套日志理解了这两套日志很多面试题都能豁然开朗。redo log重做日志负责持久性。InnoDB 的更新操作不会立刻写磁盘数据页而是先写 redo log等合适时机再刷入数据页也就是 WALWrite-Ahead Logging机制。redo log 是物理日志记录的是“在哪个页的哪个偏移量改成了什么”。如果事务提交后系统崩溃MySQL 重启时会按 redo log 重放操作把已提交但未落盘的数据恢复出来。打个比方你把现金交给银行柜员柜员先给你一张收据redo log然后才开始清点现金入账数据页。如果清点过程中来了停电通知只要收据还在后续就能对账。undo log撤销日志负责原子性。它记录的是“之前的样子”。当事务需要回滚时InnoDB 利用 undo log 把变更还原。undo log 还承载 MVCC 的多版本读功能这条线后面在隔离级别部分会用到。我在第一次接触这两个日志时总把两者混淆。后来记了一条经验口诀redo 是“我打算做”undo 是“我做过什么可以退”。一个向前恢复一个向后回退。2. 隔离级别与并发异常MySQL 到底怎么隔离2.1 四种隔离级别和三种异常SQL 标准定义了四种隔离级别从宽松到严格依次是读未提交READ UNCOMMITTED、读已提交READ COMMITTED、可重复读REPEATABLE READ、可串行化SERIALIZABLE。InnoDB 默认是可重复读。每种级别解决的并发问题不同对比如下隔离级别脏读不可重复读幻读读未提交可能可能可能读已提交不会可能可能可重复读不会不会可能InnoDB 通过间隙锁基本解决可串行化不会不会不会三种异常我用生活场景解释脏读事务 A 读到了事务 B 还没提交的数据B 随后回滚A 就拿到了一份“不存在过”的数据。好比同事口头告诉你明天放假你订了机票结果他改口说消息是假的。不可重复读事务 A 里两次查询同一条记录结果不一样。因为事务 B 在中间提交了修改。好比你在读一本连载小说第一章写主角死了第二章又活过来了。幻读事务 A 按条件查询一批记录两次查询的“行数”不同原因是事务 B 插入了新的记录。不可重复读针对的是同一行值幻读针对的是结果集数量。2.2 MVCC 与锁的协作InnoDB 隔离级别之所以有不错的性能是因为它不靠“把所有并发事务排队”来解决问题而是靠 MVCCMulti-Version Concurrency Control多版本并发控制。MVCC 的核心思路是每一行数据在存储上带有隐藏列包括事务版本号DB_TRX_ID和回滚指针DB_ROLL_PTR。每次更新会生成一个新版本旧版本保存在 undo log 链上。普通查询走“快照读”根据事务开始时的 Read View 找到对当前事务可见的版本从而避免加锁阻塞。如果业务需要强一致那就走“当前读”比如SELECT ... FOR UPDATE、UPDATE、DELETE这些必须读取最新已提交版本并对命中的记录加锁。当前读是锁快照读是版本链两者嵌套交互形成了 MySQL 的事务隔离面貌。2.3 快照读与当前读别再傻傻分不清我见过不少事务失效问题根因就是没分清快照读和当前读。比如在 REPEATABLE READ 级别下你在事务里先做了一次普通SELECT之后别的会话提交了一个新订单你再执行SELECT COUNT(*)数量不会变化因为 Read View 是第一次快照读建立的后续一直复用。但如果你的语句带了FOR UPDATE那就属于当前读读到的一定是最新已提交版本同时会对扫描范围加锁。两个方式的同时使用可能产生你预想不到的结果明明普通查询看不到某条记录当前读却能看到并锁到它。所以排查问题时先确认自己走的是哪种读。REPEATABLE READ 下InnoDB 还会使用间隙锁Gap Lock解决幻读。间隙锁锁定索引记录之间的空间防止新记录插入。间隙锁一定程度增加了死锁风险所以它并不是完全没有代价的这也是有些团队特意把隔离级别改成读已提交的原因。2.4 隔离级别怎么选项目里用哪个隔离级别不能拍脑袋。老系统默认是可重复读这没有错InnoDB 对它做了大量优化大部分电商场景都能直接跑。如果确定项目 Binlog 格式是 ROW且对并发吞吐要求很高可以改成读已提交。读已提交基本不使用间隙锁只使用行锁死锁概率更低当前读的性能更好。读未提交在任何业务场景下我都不建议使用脏读问题太严重。可串行化性能最差除非是极其低频的管理后台校验类操作否则别在生产环境碰。切换隔离级别要注意应用侧需要确保业务已经对“同一事务内两次普通查询结果可能变化”有所准备否则隐藏的 Bug 一旦上线很难排查。3. Spring 事务深入声明式事务背后的代理机制3.1 编程式事务与声明式事务Spring 提供了两种事务管理方式。第一种是编程式事务使用TransactionTemplateService public class OrderService { private final TransactionTemplate transactionTemplate; public OrderService(TransactionTemplate transactionTemplate) { this.transactionTemplate transactionTemplate; } public void createOrder(OrderBO order) { transactionTemplate.execute(status - { // 扣库存 stockMapper.deduct(order.getSkuId()); // 创建订单 orderMapper.insert(order); return null; }); } }编程式事务的优点是灵活事务边界由你明确控制出错点一目了然缺点是侵入性强业务代码里混入了事务模板逻辑方法多了以后维护成本很高。第二种是声明式事务也就是Transactional注解方式Service public class OrderService { Transactional(rollbackFor Exception.class) public void createOrder(OrderBO order) { stockMapper.deduct(order.getSkuId()); orderMapper.insert(order); } }这种方式把事务逻辑藏到了切面里业务代码干净绝大多数项目都用它。但很多人只看到了注解的便利却忽略它依赖静态代理一旦使用姿势不对事务就可能“悄悄失效”。3.2 Transactional 的执行流程Spring 的声明式事务基于 AOP 动态代理。Spring 启动时会给被Transactional标记的目标类生成一个代理对象。调用方法时请求先经过TransactionInterceptor它做的事大概分四步检查当前是否有事务根据传播行为决定新开事务、挂起事务还是直接加入已有事务。通过Connection开启事务。执行业务方法。业务方法正常返回则提交抛出异常则根据回滚规则决定回滚或继续提交。动态代理有两种实现JDK 动态代理目标类实现接口代理基于接口和 CGLIB基于生成子类也叫子类代理。Spring Boot 2.x 之后默认使用 CGLIB。这个差异很重要因为直接决定了一个经典失效场景方法如果是finalCGLIB 没法重写事务也就失效了。3.3 事务传播行为速查Transactional的propagation属性定义了事务传播行为常用的是REQUIRED也是默认值。我整理了一份速查传播行为含义典型使用场景REQUIRED有事务就加入没有就新建默认绝大多数业务REQUIRES_NEW挂起当前事务新建一个独立事务异步日志、审计记录避免随主事务回滚NESTED内嵌事务基于保存点部分业务希望部分回滚SUPPORTS有事务就加入没有就正常执行只读查询辅助方法NOT_SUPPORTED挂起当前事务非事务执行不希望在事务里执行的操作MANDATORY必须有事务否则抛异常强制要求调用方处于事务中NEVER必须没有事务否则抛异常纯查询校验场景传播行为里最容易误用的是REQUIRES_NEW。很多人以为它是“嵌套事务”其实是“完全独立事务”新事务的提交回滚不会影响外层事务。NESTED 才更接近“嵌套”的概念但它依赖数据库保存点底层支持有限。3.4 回滚规则Transactional默认只在抛出RuntimeException或Error时回滚检查异常比如IOException默认不触发回滚。这个设计初衷是Spring 认为检查异常是“业务可预期的分支”不一定要回滚。但实际开发里这个默认值经常害人。你在事务里调用远程服务对方返回了业务错误你可能抛一个自定义检查异常如果没有配置rollbackFor事务会照常提交。所以我在项目里的习惯是Transactional(rollbackFor Exception.class)除非有特殊场景否则统一指定rollbackFor Exception.class让所有异常都能触发回滚从源头减少“以为回滚了其实没回滚”的线上事故。4. Spring 事务失效场景2026 年最容易踩的坑4.1 自调用最隐蔽的坑自调用是“事务失效”里出现频率最高的场景。同一类内部一个方法调用另一个带Transactional的方法事务会失效。因为 Spring 事务代理只在外部调用时生效内部this.method()直接绕过了代理对象事务拦截器根本看不到这次调用。Service public class OrderService { Transactional(rollbackFor Exception.class) public void createOrder(OrderBO order) { stockMapper.deduct(order.getSkuId()); orderMapper.insert(order); } public void createOrderWithLog(OrderBO order) { // 这是 this 调用Transactional 失效 this.createOrder(order); // 其他逻辑 } }解决方案有三种我按推荐程度排列把createOrder拆到另一个 Spring Bean比如OrderTransactionService让事务方法不经this调用。在类内部注入代理自身Autowired Lazy private OrderService self;调用时用self.createOrder(order)。放弃声明式事务改成TransactionTemplate编程式事务不依赖代理。很多老项目里常见的场景是对外方法调用内部私有事务方法功能看起来正常出问题时才发现日志里根本没有事务开启记录。自调用就是这类问题的头号嫌疑。4.2 方法可见性与 final 修饰符Transactional加在private方法上事务不生效。原因是代理机制的限制JDK 动态代理只能拦截接口方法CGLIB 也只能覆盖非 private、非 final 的方法。Spring 官方明确说明Transactional只支持 public 方法。我见过一个小伙伴把Transactional加在private辅助方法上恍然大悟后改成 public事务就生效了。还有个场景是 CGLIB 代理遇到final方法直接报错提示Cannot subclass final class或者代理创建失败。解决方式就是去掉 final或者让目标方法不走类代理。4.3 异常被吞你以为抛了其实没有这是最“冤枉”的失效场景代码逻辑完全正确注解也加了但事务还是没回滚。原因通常是异常被 catch 住但没有重新抛出去。Transactional(rollbackFor Exception.class) public void createOrder(OrderBO order) { try { stockMapper.deduct(order.getSkuId()); orderMapper.insert(order); } catch (Exception e) { log.error(扣库存失败, e); // 这里没有重新抛出异常事务正常提交 } }事务拦截器是在方法调用外部感知异常的。异常被捕获后方法正常返回Spring 认为“你执行成功了”于是提交。解决办法很简单捕获后重新抛出抛出前可以做日志、告警、上下文清理。捕获异常并吞掉是事务回滚失效里最危险的一种写法。4.4 回滚策略配置错误异常抛出去了但事务还是没回滚那可能碰到了回滚规则问题。Transactional public void createOrder() throws IOException { throw new IOException(SQL 状态未知); }这段代码用的是默认回滚策略只回滚RuntimeException和Error。IOException是检查异常所以事务会在异常抛出后依然提交。线上数据就会出现代码报错了数据库却改了。解决方式就是显式声明Transactional(rollbackFor Exception.class)或者如果你只想针对特定异常回滚Transactional(noRollbackFor IllegalArgumentException.class)noRollbackFor的优先级高于rollbackFor这两个属性排优先级时容易搞混我建议平时只用rollbackFor特殊情况才用noRollbackFor。4.5 缺少事务管理器或多数据源问题当项目有多个数据源时Transactional默认使用PlatformTransactionManager自动配置的那个。如果你在操作数据源 A事务管理器绑定的却是数据源 B那事务操作的就是另一个连接数据源 A 的操作完全没有事务保护。这种多数据源场景下必须显式指定事务管理器Transactional(transactionManager orderTransactionManager, rollbackFor Exception.class)还有一种比较隐蔽的情况手动new出来的类不经过 Spring 容器没有代理对象注解自然失效。比如OrderService service new OrderService();这时候别指望Transactional有任何作用。4.6 Spring 事务失效场景速查表失效场景根本原因解决方式同一类内自调用绕过了代理对象拆分 Bean、注入代理、编程式事务private 方法代理无法拦截改成 publicfinal 方法/类CGLIB 无法重写去掉 final异常被吞掉事务拦截器感知不到异常捕获后重新抛出检查异常未配置 rollbackFor默认回滚规则不覆盖指定 rollbackFor事务管理器与数据源不匹配两个连接明确 transactionManager方法在非 Spring Bean 中调用没有代理由 Spring 托管新线程中调用事务方法事务资源与线程绑定在子线程内单独开启事务这张表是我排查线上问题时最常用的清单。遇到“事务没生效”先对照表格逐项排查比盲目翻日志效率高很多。5. 事务排查与调试怎么确认事务真的生效了5.1 打开事务日志一眼看穿排查事务问题第一步不是改代码而是开日志。Spring 事务相关的日志级别调到 TRACE你能看到事务的创建、提交和回滚全过程。在application.yml里这样配置logging: level: org.springframework.transaction: TRACE org.springframework.jdbc.datasource: TRACE启动后调用对应接口观察日志关键字Creating new transaction with name说明事务新创建了。Participating in existing transaction说明加入了已有事务。Committing transaction说明正常提交。Rolling back transaction说明回滚触发。如果调用接口后根本看不到Creating new transaction之类的日志那大概率就是事务根本没开启直接定位到失效场景排查。5.2 用 TransactionSynchronizationManager 验证这是 Spring 内部的一个工具类维护当前线程的事务资源。我们可以在代码里临时加个静态导入来验证事务状态import org.springframework.transaction.support.TransactionSynchronizationManager; public boolean isTransactionActive() { return TransactionSynchronizationManager.isActualTransactionActive(); }我在实践中还喜欢在当前事务里直接打印事务名称TransactionSynchronizationManager.getCurrentTransactionName();如果返回 null说明当前方法没有进入事务上下文。这个手段在排查自调用问题时特别好用因为外部调用进入事务方法时名称正常内部调用却显示 null。5.3 线程与事务的边界Spring 事务资源和当前线程绑定这也导致了一个经典失效场景主线程开启事务再通过线程池或异步线程执行某个数据库操作那个子线程里的操作不在事务范围内。Transactional(rollbackFor Exception.class) public void createOrder(OrderBO order) { // 主线程逻辑 CompletableFuture.runAsync(() - { // 子线程里执行不参与主事务 stockMapper.deduct(order.getSkuId()); }); }主线程执行结束时子线程可能还没执行完或者子线程执行失败主线程也不知道。这种写法绝对不能用来替代事务。异步操作要单独设计事务边界要么让异步方法自己开启事务要么把整个链路放到同一条线程里完成。5.4 我的调试流程经验遇到“事务不回滚”的反馈我一般会按以下顺序排查看业务方法是否真的抛异常了是否被 catch 吞掉。看日志里有没有Rolling back transaction。看方法调用来源是不是内部this调用。看异常类型检查rollbackFor是否覆盖。看事务管理器对应的数据源确认没有多数据源串线。看方法是否属于 Spring 管理的单例 Bean。这套流程几分钟就能跑完大部分问题能在前两步暴露。真正麻烦的往往是代码复杂、日志不全的老模块所以我建议新写的业务代码必须保留事务日志输出别等出问题了再补。6. 2026 实战设计建议事务不止是一个注解6.1 事务边界和性能怎么平衡事务太小会破坏业务一致性太大会持有数据库锁拖垮并发。我自己的原则是事务方法里做数据库操作不做远程调用不做长时间 IO不做等待。典型反例是在Transactional方法里同步调用第三方支付接口、发短信、推送消息。这些网络调用的时间不可控如果你把它们放在事务里事务会一直持有数据库连接和行锁数据库连接池很快会被耗尽其他请求全部排队等待系统吞吐量瞬间崩掉。更合理的做法是先把数据库核心操作放事务里完成提交成功后再把“通知外部系统”这类事件放到事务提交后执行。Spring 里可以用TransactionalEventListener(phase TransactionPhase.AFTER_COMMIT)这样既能保证一致性又不会拖长事务。另外针对纯查询方法习惯上可以加Transactional(readOnly true)。这在 Spring Data JPA 场景下能触发 Flush Mode 为 MANUAL 等优化但对 JDBC 而言它更多是提示语义不能把它当强制约束底部连接照样可以执行写操作。6.2 分布式事务本地事务不够用怎么办到了 2026 年微服务和分库分表已经成为常态单靠 MySQL 本地事务解决不了跨库、跨服务的一致性。但很多人的第一反应仍然是在方法上堆Transactional结果只对本地库生效远程服务的那部分根本没有保护。拿“订单与库存”这个经典场景举例订单库和库存库可能分属不同服务甚至在物理上就是两个库MySQL 事务帮不了你。此时常见的方案是最终一致性事务模式可靠消息最终一致本地事务先写业务数据和消息记录提交后由消息中间件把消息可靠投递给库存服务库存服务消费后执行扣减。消息表发送失败可以定时任务补偿达到最终一致。SAGA 模式把一个长事务拆成多个本地事务每个本地事务执行完发布事件下一个服务消费并执行。某一步失败时执行反向补偿操作。TCC 模式Try 阶段锁定资源Confirm 阶段真正执行Cancel 阶段回滚要求各个服务都要实现三段逻辑开发量最大但能保证较强的即时一致性。我特别想分享的一条经验不要在事务里调用远程服务也不要在事务里依赖远程返回结果。即使你把回滚规则写对了远程服务 A 扣款成功本地订单创建失败你本地可以回滚但远程 A 那边的扣款不会跟着回滚只能靠人工补偿或对账系统纠偏。事务边界必须画在你能完全控制的资源范围内。6.3 幂等设计比没完没了的重试更可靠很多时候数据不一致不是因为事务没生效而是因为消息重复投递、请求重试导致业务逻辑执行了两次。如果外部系统、消息中间件出现重复事务本身是无能为力的。我给交易类服务加事务的同时一定会做幂等设计数据库唯一索引兜底比如订单号、流水号设唯一键。在入口处通过幂等表或 Redis 锁判断请求是否已处理。对外接口支持幂等键参数重复提交返回原结果。幂等加上正确的事务边界才能把数据一致性做到“即使出现异常重试最终状态还是对的”。事务是兜底但不要让事务成为重复操作的借口。写在最后的实操经验如果你让我总结一条最核心的心得那就是事务不是一个注解而是一条边界边界画在哪里决定了你能保护多少数据。回滚机制、隔离级别、传播行为都是围绕这条边界展开的。先想清楚业务里哪些操作必须同生共死哪些可以独立失败再决定Transactional放在哪个方法、有没有正确配置。项目里每次出现“库存和订单对不上”这类事故回头检查几乎都是事务边界画错了地方要么多画了把远程调用也圈进事务要么少画了让异常被吞掉。建议你把文章末尾的失效场景速查表打印出来放到工位上下次遇到诡异的“没回滚”从第一行往下捋大概率能快速定位。 MySQL事务与Spring事务失效场景全解析：从原理到排查实战
先说一句掏心窝的话在数据库系统里并发下的数据一致性永远是最让人头疼的问题。无论是订单、库存还是支付几乎每个核心业务都依赖 MySQL 事务这张安全网但真正深入使用几年后你会发现难的不是背出 ACID 那四个字母而是在 Spring 项目里把每一条 Transactional 都写对、让它真的生效。这篇文章按照“底层原理 → 隔离机制 → Spring 实现 → 失效场景 → 排查技巧 → 架构设计”的顺序把 MySQL 事务从理论到实战完整串一遍重点给你讲透 2026 年面试和线上故障里最高频的 Spring 事务失效场景适合刚接触事务的后端开发也适合准备做一次系统性复盘的老手。1. 从 ACID 到 MySQL 底层机制事务为什么是数据一致性的地基1.1 一次扣库存事故告诉我们什么前年我在处理一个“订单与库存”联调项目时同事发现库存明明是扣减成功的但订单表里查不到记录最后盘库怎么都对不上。排查后确认扣库存和建订单是两个操作分别开了两个数据库连接第一个提交成功了第二个抛异常了但因为两者之间没有公共事务边界数据一致性当场崩塌。这个场景其实特别典型。你写业务代码的时候脑子里想的是“扣库存、建订单、更新用户账单”这一整串动作应该是一个整体但数据库看到的却是一个又一个独立连接。没有事务任何一步失败都会把系统推入中间状态要么库存少了订单没产生要么钱扣了库存没减。所以事务的本质不是“更快”或“更好用”而是给一组逻辑上不可分割的操作提供一个明确的边界边界内要么全部成功要么全部回滚。1.2 ACID 四属性缺一不可ACID 是事务的四个核心属性原子性、一致性、隔离性、持久性。这些年我面试过不少候选人大部分能背出这四个词但问到一个具体业务怎么回滚、日志怎么保证崩溃恢复就卡住了。原子性Atomicity事务里的操作像一个不可分割的原子要么全部提交要么全部回滚。数据库通过 undo log 实现这一点后面会展开。一致性Consistency事务执行前后数据库始终处于合法状态。这包含数据库层面的约束也包含业务层面的规则。一致性其实是 ACID 的“目的”其他三个属性都是为它服务的。隔离性Isolation多个事务并发执行时一个事务不会被其他事务的中间状态干扰。隔离性并不是“绝对隔离”而是通过隔离级别来定义干扰程度。持久性Durability事务一旦提交修改就永久保存哪怕系统崩溃、断电也不会丢失。这四个属性不是平等的并列关系。一致性是目标原子性、隔离性、持久性是手段。你没法单独牺牲某一个来换取其他因为最终都是为了不让数据“看起来没问题但实际烂掉”。1.3 InnoDB 的两大利器redo log 与 undo logMySQL 默认的存储引擎是 InnoDB它实现 ACID 主要靠两套日志理解了这两套日志很多面试题都能豁然开朗。redo log重做日志负责持久性。InnoDB 的更新操作不会立刻写磁盘数据页而是先写 redo log等合适时机再刷入数据页也就是 WALWrite-Ahead Logging机制。redo log 是物理日志记录的是“在哪个页的哪个偏移量改成了什么”。如果事务提交后系统崩溃MySQL 重启时会按 redo log 重放操作把已提交但未落盘的数据恢复出来。打个比方你把现金交给银行柜员柜员先给你一张收据redo log然后才开始清点现金入账数据页。如果清点过程中来了停电通知只要收据还在后续就能对账。undo log撤销日志负责原子性。它记录的是“之前的样子”。当事务需要回滚时InnoDB 利用 undo log 把变更还原。undo log 还承载 MVCC 的多版本读功能这条线后面在隔离级别部分会用到。我在第一次接触这两个日志时总把两者混淆。后来记了一条经验口诀redo 是“我打算做”undo 是“我做过什么可以退”。一个向前恢复一个向后回退。2. 隔离级别与并发异常MySQL 到底怎么隔离2.1 四种隔离级别和三种异常SQL 标准定义了四种隔离级别从宽松到严格依次是读未提交READ UNCOMMITTED、读已提交READ COMMITTED、可重复读REPEATABLE READ、可串行化SERIALIZABLE。InnoDB 默认是可重复读。每种级别解决的并发问题不同对比如下隔离级别脏读不可重复读幻读读未提交可能可能可能读已提交不会可能可能可重复读不会不会可能InnoDB 通过间隙锁基本解决可串行化不会不会不会三种异常我用生活场景解释脏读事务 A 读到了事务 B 还没提交的数据B 随后回滚A 就拿到了一份“不存在过”的数据。好比同事口头告诉你明天放假你订了机票结果他改口说消息是假的。不可重复读事务 A 里两次查询同一条记录结果不一样。因为事务 B 在中间提交了修改。好比你在读一本连载小说第一章写主角死了第二章又活过来了。幻读事务 A 按条件查询一批记录两次查询的“行数”不同原因是事务 B 插入了新的记录。不可重复读针对的是同一行值幻读针对的是结果集数量。2.2 MVCC 与锁的协作InnoDB 隔离级别之所以有不错的性能是因为它不靠“把所有并发事务排队”来解决问题而是靠 MVCCMulti-Version Concurrency Control多版本并发控制。MVCC 的核心思路是每一行数据在存储上带有隐藏列包括事务版本号DB_TRX_ID和回滚指针DB_ROLL_PTR。每次更新会生成一个新版本旧版本保存在 undo log 链上。普通查询走“快照读”根据事务开始时的 Read View 找到对当前事务可见的版本从而避免加锁阻塞。如果业务需要强一致那就走“当前读”比如SELECT ... FOR UPDATE、UPDATE、DELETE这些必须读取最新已提交版本并对命中的记录加锁。当前读是锁快照读是版本链两者嵌套交互形成了 MySQL 的事务隔离面貌。2.3 快照读与当前读别再傻傻分不清我见过不少事务失效问题根因就是没分清快照读和当前读。比如在 REPEATABLE READ 级别下你在事务里先做了一次普通SELECT之后别的会话提交了一个新订单你再执行SELECT COUNT(*)数量不会变化因为 Read View 是第一次快照读建立的后续一直复用。但如果你的语句带了FOR UPDATE那就属于当前读读到的一定是最新已提交版本同时会对扫描范围加锁。两个方式的同时使用可能产生你预想不到的结果明明普通查询看不到某条记录当前读却能看到并锁到它。所以排查问题时先确认自己走的是哪种读。REPEATABLE READ 下InnoDB 还会使用间隙锁Gap Lock解决幻读。间隙锁锁定索引记录之间的空间防止新记录插入。间隙锁一定程度增加了死锁风险所以它并不是完全没有代价的这也是有些团队特意把隔离级别改成读已提交的原因。2.4 隔离级别怎么选项目里用哪个隔离级别不能拍脑袋。老系统默认是可重复读这没有错InnoDB 对它做了大量优化大部分电商场景都能直接跑。如果确定项目 Binlog 格式是 ROW且对并发吞吐要求很高可以改成读已提交。读已提交基本不使用间隙锁只使用行锁死锁概率更低当前读的性能更好。读未提交在任何业务场景下我都不建议使用脏读问题太严重。可串行化性能最差除非是极其低频的管理后台校验类操作否则别在生产环境碰。切换隔离级别要注意应用侧需要确保业务已经对“同一事务内两次普通查询结果可能变化”有所准备否则隐藏的 Bug 一旦上线很难排查。3. Spring 事务深入声明式事务背后的代理机制3.1 编程式事务与声明式事务Spring 提供了两种事务管理方式。第一种是编程式事务使用TransactionTemplateService public class OrderService { private final TransactionTemplate transactionTemplate; public OrderService(TransactionTemplate transactionTemplate) { this.transactionTemplate transactionTemplate; } public void createOrder(OrderBO order) { transactionTemplate.execute(status - { // 扣库存 stockMapper.deduct(order.getSkuId()); // 创建订单 orderMapper.insert(order); return null; }); } }编程式事务的优点是灵活事务边界由你明确控制出错点一目了然缺点是侵入性强业务代码里混入了事务模板逻辑方法多了以后维护成本很高。第二种是声明式事务也就是Transactional注解方式Service public class OrderService { Transactional(rollbackFor Exception.class) public void createOrder(OrderBO order) { stockMapper.deduct(order.getSkuId()); orderMapper.insert(order); } }这种方式把事务逻辑藏到了切面里业务代码干净绝大多数项目都用它。但很多人只看到了注解的便利却忽略它依赖静态代理一旦使用姿势不对事务就可能“悄悄失效”。3.2 Transactional 的执行流程Spring 的声明式事务基于 AOP 动态代理。Spring 启动时会给被Transactional标记的目标类生成一个代理对象。调用方法时请求先经过TransactionInterceptor它做的事大概分四步检查当前是否有事务根据传播行为决定新开事务、挂起事务还是直接加入已有事务。通过Connection开启事务。执行业务方法。业务方法正常返回则提交抛出异常则根据回滚规则决定回滚或继续提交。动态代理有两种实现JDK 动态代理目标类实现接口代理基于接口和 CGLIB基于生成子类也叫子类代理。Spring Boot 2.x 之后默认使用 CGLIB。这个差异很重要因为直接决定了一个经典失效场景方法如果是finalCGLIB 没法重写事务也就失效了。3.3 事务传播行为速查Transactional的propagation属性定义了事务传播行为常用的是REQUIRED也是默认值。我整理了一份速查传播行为含义典型使用场景REQUIRED有事务就加入没有就新建默认绝大多数业务REQUIRES_NEW挂起当前事务新建一个独立事务异步日志、审计记录避免随主事务回滚NESTED内嵌事务基于保存点部分业务希望部分回滚SUPPORTS有事务就加入没有就正常执行只读查询辅助方法NOT_SUPPORTED挂起当前事务非事务执行不希望在事务里执行的操作MANDATORY必须有事务否则抛异常强制要求调用方处于事务中NEVER必须没有事务否则抛异常纯查询校验场景传播行为里最容易误用的是REQUIRES_NEW。很多人以为它是“嵌套事务”其实是“完全独立事务”新事务的提交回滚不会影响外层事务。NESTED 才更接近“嵌套”的概念但它依赖数据库保存点底层支持有限。3.4 回滚规则Transactional默认只在抛出RuntimeException或Error时回滚检查异常比如IOException默认不触发回滚。这个设计初衷是Spring 认为检查异常是“业务可预期的分支”不一定要回滚。但实际开发里这个默认值经常害人。你在事务里调用远程服务对方返回了业务错误你可能抛一个自定义检查异常如果没有配置rollbackFor事务会照常提交。所以我在项目里的习惯是Transactional(rollbackFor Exception.class)除非有特殊场景否则统一指定rollbackFor Exception.class让所有异常都能触发回滚从源头减少“以为回滚了其实没回滚”的线上事故。4. Spring 事务失效场景2026 年最容易踩的坑4.1 自调用最隐蔽的坑自调用是“事务失效”里出现频率最高的场景。同一类内部一个方法调用另一个带Transactional的方法事务会失效。因为 Spring 事务代理只在外部调用时生效内部this.method()直接绕过了代理对象事务拦截器根本看不到这次调用。Service public class OrderService { Transactional(rollbackFor Exception.class) public void createOrder(OrderBO order) { stockMapper.deduct(order.getSkuId()); orderMapper.insert(order); } public void createOrderWithLog(OrderBO order) { // 这是 this 调用Transactional 失效 this.createOrder(order); // 其他逻辑 } }解决方案有三种我按推荐程度排列把createOrder拆到另一个 Spring Bean比如OrderTransactionService让事务方法不经this调用。在类内部注入代理自身Autowired Lazy private OrderService self;调用时用self.createOrder(order)。放弃声明式事务改成TransactionTemplate编程式事务不依赖代理。很多老项目里常见的场景是对外方法调用内部私有事务方法功能看起来正常出问题时才发现日志里根本没有事务开启记录。自调用就是这类问题的头号嫌疑。4.2 方法可见性与 final 修饰符Transactional加在private方法上事务不生效。原因是代理机制的限制JDK 动态代理只能拦截接口方法CGLIB 也只能覆盖非 private、非 final 的方法。Spring 官方明确说明Transactional只支持 public 方法。我见过一个小伙伴把Transactional加在private辅助方法上恍然大悟后改成 public事务就生效了。还有个场景是 CGLIB 代理遇到final方法直接报错提示Cannot subclass final class或者代理创建失败。解决方式就是去掉 final或者让目标方法不走类代理。4.3 异常被吞你以为抛了其实没有这是最“冤枉”的失效场景代码逻辑完全正确注解也加了但事务还是没回滚。原因通常是异常被 catch 住但没有重新抛出去。Transactional(rollbackFor Exception.class) public void createOrder(OrderBO order) { try { stockMapper.deduct(order.getSkuId()); orderMapper.insert(order); } catch (Exception e) { log.error(扣库存失败, e); // 这里没有重新抛出异常事务正常提交 } }事务拦截器是在方法调用外部感知异常的。异常被捕获后方法正常返回Spring 认为“你执行成功了”于是提交。解决办法很简单捕获后重新抛出抛出前可以做日志、告警、上下文清理。捕获异常并吞掉是事务回滚失效里最危险的一种写法。4.4 回滚策略配置错误异常抛出去了但事务还是没回滚那可能碰到了回滚规则问题。Transactional public void createOrder() throws IOException { throw new IOException(SQL 状态未知); }这段代码用的是默认回滚策略只回滚RuntimeException和Error。IOException是检查异常所以事务会在异常抛出后依然提交。线上数据就会出现代码报错了数据库却改了。解决方式就是显式声明Transactional(rollbackFor Exception.class)或者如果你只想针对特定异常回滚Transactional(noRollbackFor IllegalArgumentException.class)noRollbackFor的优先级高于rollbackFor这两个属性排优先级时容易搞混我建议平时只用rollbackFor特殊情况才用noRollbackFor。4.5 缺少事务管理器或多数据源问题当项目有多个数据源时Transactional默认使用PlatformTransactionManager自动配置的那个。如果你在操作数据源 A事务管理器绑定的却是数据源 B那事务操作的就是另一个连接数据源 A 的操作完全没有事务保护。这种多数据源场景下必须显式指定事务管理器Transactional(transactionManager orderTransactionManager, rollbackFor Exception.class)还有一种比较隐蔽的情况手动new出来的类不经过 Spring 容器没有代理对象注解自然失效。比如OrderService service new OrderService();这时候别指望Transactional有任何作用。4.6 Spring 事务失效场景速查表失效场景根本原因解决方式同一类内自调用绕过了代理对象拆分 Bean、注入代理、编程式事务private 方法代理无法拦截改成 publicfinal 方法/类CGLIB 无法重写去掉 final异常被吞掉事务拦截器感知不到异常捕获后重新抛出检查异常未配置 rollbackFor默认回滚规则不覆盖指定 rollbackFor事务管理器与数据源不匹配两个连接明确 transactionManager方法在非 Spring Bean 中调用没有代理由 Spring 托管新线程中调用事务方法事务资源与线程绑定在子线程内单独开启事务这张表是我排查线上问题时最常用的清单。遇到“事务没生效”先对照表格逐项排查比盲目翻日志效率高很多。5. 事务排查与调试怎么确认事务真的生效了5.1 打开事务日志一眼看穿排查事务问题第一步不是改代码而是开日志。Spring 事务相关的日志级别调到 TRACE你能看到事务的创建、提交和回滚全过程。在application.yml里这样配置logging: level: org.springframework.transaction: TRACE org.springframework.jdbc.datasource: TRACE启动后调用对应接口观察日志关键字Creating new transaction with name说明事务新创建了。Participating in existing transaction说明加入了已有事务。Committing transaction说明正常提交。Rolling back transaction说明回滚触发。如果调用接口后根本看不到Creating new transaction之类的日志那大概率就是事务根本没开启直接定位到失效场景排查。5.2 用 TransactionSynchronizationManager 验证这是 Spring 内部的一个工具类维护当前线程的事务资源。我们可以在代码里临时加个静态导入来验证事务状态import org.springframework.transaction.support.TransactionSynchronizationManager; public boolean isTransactionActive() { return TransactionSynchronizationManager.isActualTransactionActive(); }我在实践中还喜欢在当前事务里直接打印事务名称TransactionSynchronizationManager.getCurrentTransactionName();如果返回 null说明当前方法没有进入事务上下文。这个手段在排查自调用问题时特别好用因为外部调用进入事务方法时名称正常内部调用却显示 null。5.3 线程与事务的边界Spring 事务资源和当前线程绑定这也导致了一个经典失效场景主线程开启事务再通过线程池或异步线程执行某个数据库操作那个子线程里的操作不在事务范围内。Transactional(rollbackFor Exception.class) public void createOrder(OrderBO order) { // 主线程逻辑 CompletableFuture.runAsync(() - { // 子线程里执行不参与主事务 stockMapper.deduct(order.getSkuId()); }); }主线程执行结束时子线程可能还没执行完或者子线程执行失败主线程也不知道。这种写法绝对不能用来替代事务。异步操作要单独设计事务边界要么让异步方法自己开启事务要么把整个链路放到同一条线程里完成。5.4 我的调试流程经验遇到“事务不回滚”的反馈我一般会按以下顺序排查看业务方法是否真的抛异常了是否被 catch 吞掉。看日志里有没有Rolling back transaction。看方法调用来源是不是内部this调用。看异常类型检查rollbackFor是否覆盖。看事务管理器对应的数据源确认没有多数据源串线。看方法是否属于 Spring 管理的单例 Bean。这套流程几分钟就能跑完大部分问题能在前两步暴露。真正麻烦的往往是代码复杂、日志不全的老模块所以我建议新写的业务代码必须保留事务日志输出别等出问题了再补。6. 2026 实战设计建议事务不止是一个注解6.1 事务边界和性能怎么平衡事务太小会破坏业务一致性太大会持有数据库锁拖垮并发。我自己的原则是事务方法里做数据库操作不做远程调用不做长时间 IO不做等待。典型反例是在Transactional方法里同步调用第三方支付接口、发短信、推送消息。这些网络调用的时间不可控如果你把它们放在事务里事务会一直持有数据库连接和行锁数据库连接池很快会被耗尽其他请求全部排队等待系统吞吐量瞬间崩掉。更合理的做法是先把数据库核心操作放事务里完成提交成功后再把“通知外部系统”这类事件放到事务提交后执行。Spring 里可以用TransactionalEventListener(phase TransactionPhase.AFTER_COMMIT)这样既能保证一致性又不会拖长事务。另外针对纯查询方法习惯上可以加Transactional(readOnly true)。这在 Spring Data JPA 场景下能触发 Flush Mode 为 MANUAL 等优化但对 JDBC 而言它更多是提示语义不能把它当强制约束底部连接照样可以执行写操作。6.2 分布式事务本地事务不够用怎么办到了 2026 年微服务和分库分表已经成为常态单靠 MySQL 本地事务解决不了跨库、跨服务的一致性。但很多人的第一反应仍然是在方法上堆Transactional结果只对本地库生效远程服务的那部分根本没有保护。拿“订单与库存”这个经典场景举例订单库和库存库可能分属不同服务甚至在物理上就是两个库MySQL 事务帮不了你。此时常见的方案是最终一致性事务模式可靠消息最终一致本地事务先写业务数据和消息记录提交后由消息中间件把消息可靠投递给库存服务库存服务消费后执行扣减。消息表发送失败可以定时任务补偿达到最终一致。SAGA 模式把一个长事务拆成多个本地事务每个本地事务执行完发布事件下一个服务消费并执行。某一步失败时执行反向补偿操作。TCC 模式Try 阶段锁定资源Confirm 阶段真正执行Cancel 阶段回滚要求各个服务都要实现三段逻辑开发量最大但能保证较强的即时一致性。我特别想分享的一条经验不要在事务里调用远程服务也不要在事务里依赖远程返回结果。即使你把回滚规则写对了远程服务 A 扣款成功本地订单创建失败你本地可以回滚但远程 A 那边的扣款不会跟着回滚只能靠人工补偿或对账系统纠偏。事务边界必须画在你能完全控制的资源范围内。6.3 幂等设计比没完没了的重试更可靠很多时候数据不一致不是因为事务没生效而是因为消息重复投递、请求重试导致业务逻辑执行了两次。如果外部系统、消息中间件出现重复事务本身是无能为力的。我给交易类服务加事务的同时一定会做幂等设计数据库唯一索引兜底比如订单号、流水号设唯一键。在入口处通过幂等表或 Redis 锁判断请求是否已处理。对外接口支持幂等键参数重复提交返回原结果。幂等加上正确的事务边界才能把数据一致性做到“即使出现异常重试最终状态还是对的”。事务是兜底但不要让事务成为重复操作的借口。写在最后的实操经验如果你让我总结一条最核心的心得那就是事务不是一个注解而是一条边界边界画在哪里决定了你能保护多少数据。回滚机制、隔离级别、传播行为都是围绕这条边界展开的。先想清楚业务里哪些操作必须同生共死哪些可以独立失败再决定Transactional放在哪个方法、有没有正确配置。项目里每次出现“库存和订单对不上”这类事故回头检查几乎都是事务边界画错了地方要么多画了把远程调用也圈进事务要么少画了让异常被吞掉。建议你把文章末尾的失效场景速查表打印出来放到工位上下次遇到诡异的“没回滚”从第一行往下捋大概率能快速定位。