一、事务传播机制核心判断思路1. 三个问题外层调用方有没有事务内层失败的时候要不要影响外层事务内层抛异常外层要不要回滚内层是否需要独立提交 / 回滚还是只是子事务2. 判断流程图3. 具体传播机制使用规则1) REQUIRED默认规则有就加入外层事务没有自己新建。场景serviceA 开启事务调用 serviceBA、B 在同一个事务。B 抛异常A 一起回滚A 抛异常 B 也回滚。适合大部分新增修改业务CRUD绝大多数情况不用手动改传播属性。2) SUPPORTS规则如果外层有事务就用外层事务没有事务就直接非事务运行。适合select 查询方法不需要强制事务。3) MANDATORY禁止外层无事务调用防止漏开事务。一般框架内部使用业务代码很少写。场景内部核心更新方法要求调用者必须开启事务否则抛IllegalTransactionStateException。适用内层一定要跑在事务里面外层没事务直接报错4) REQUIRES_NEW规则调用 B 的时候挂起 A 的事务开启 B 全新独立事务B 提交 / 回滚完全独立B 结束恢复 A 的挂起事务。适用内层需要独立事务内层失败不影响外层典型业务场景操作日志、审计日志、错误记录。主业务失败回滚但是错误日志必须入库保存不能跟着业务一起回滚。坑如果不 catch内层抛出异常直接抛给外层外层也会回滚内层独立事务回滚了外层代码必须捕获内层异常。5) NOT_SUPPORTED规则如果外层有事务先挂起外层事务本方法非事务执行。方法不能运行在事务中场景大批量数据导入大批量查询不想占用数据库事务连接避免长事务。6) NEVER规则禁止外层存在事务如果外层有事务直接抛异常。适用业务几乎不用用于校验。7) NESTEDJDBC savepoint 保存点规则嵌套事务。内层回滚只回滚到 savepoint外层事务还可以继续提交外层回滚整个全部回滚内层提交也跟着回滚。适合场景一个大业务分多个子步骤子步骤可以单独回滚但外层整体失败全部回滚。限制只支持 JDBC 事务不支持 JTA 分布式事务。MySQL InnoDB 支持 savepoint。和 REQUIRES_NEW 区别不是新开独立事务是外层事务里面设置保存点 savepointREQUIRES_NEW vs NESTEDREQUIRES_NEW完全独立两个事务内层提交不受外层控制外层回滚内层已经提交的数据不受影响。NESTED属于同一个物理事务设置保存点外层一旦回滚嵌套部分全部回滚。二、事务使用场景事务的核心原则事务用来保证一组数据库操作「要么全部成功要么全部失败」ACID单条 SQL 天然是事务不需要额外加 Transactional。注MySQL InnoDB每一条 DMLinsert/update/delete本身就是一个自动提交的独立事务。1.需要事务的场景业务需要多条数据库操作逻辑上必须原子绑定一部分成功一部分失败是错误数据。1) 多写操作业务要求原子性- 例转账A 扣钱、B 加钱扣钱成功加钱失败数据不能出现 A 钱少了 B 没多。- 例订单业务创建订单、扣库存、生成流水、扣余额任意一步失败全部回滚。- 例主表 子表同时保存保存订单 保存订单明细不能订单存成功明细丢失。2) 读 写组合需要数据一致性先查询再根据查询结果做更新过程中不允许其他线程修改这条数据。例扣库存先查库存 0再扣减。不加事务会出现**超卖**。注意单纯 select 不会加锁需要锁要配合Transactional 悲观锁 / select ... for update或者乐观锁版本号3)业务失败必须回滚中间全部变更调用多个 Mapper/DAO中间抛出异常前面已经入库的数据必须撤销。4) 需要控制隔离级别、避免脏读 / 不可重复读业务对读取数据一致性要求高需要指定隔离级别。5) 需要用到传播行为特性比如日志需要独立事务 REQUIRES_NEW嵌套业务需要 NESTED保存点2.不需要事务的场景1) 只有单条 SQLinsert /update/delete// 单条更新数据库本身自动事务不需要 Transactional userMapper.updateById(user);就算不加注解这条语句要么成功要么失败不会半截执行。再加事务属于多余开销开启事务、提交都有性能损耗误区所有 service 方法统一加 Transactional造成不必要事务开启连接占用时间变长高并发下加剧数据库锁、长事务问题。2) 纯查询方法没有任何写操作普通列表查询、详情查询只读没有新增修改删除。不要随便加Transactional(readOnly true)不是不能加但不是必须。补充readOnlytrue作用给底层数据库驱动一个 hint部分驱动会做优化不会锁表不能防止数据被别的线程修改。如果只是简单查询直接去掉注解性能更好。3) 业务允许部分成功部分失败批量导入允许一部分成功、一部分失败失败记录单独记录日志不希望全部回滚。这种场景反而不能加大事务捕获单条异常跳过错误继续处理下一条。4) 纯内存逻辑完全不操作数据库方法只有参数校验、调用 RPC、调用 http、内存计算没有 DB 操作加事务毫无意义3. 灰色场景容易踩坑1) 方法里面有 DB 操作也有 RPC/HTTP 调用Transactional public void createOrder(){ orderMapper.insert(order); // 远程调用网络超时卡住 remotePayApi.call(); }RPC 网络 IO 放在事务内部 → 长事务大坑。数据库连接长期不释放锁持有时间变长数据库压力暴涨。正确把远程调用移出事务边界事务尽量小只包裹数据库操作。2) 循环批量处理// 错误大事务全部在一个事务数据量大会回滚日志暴涨锁时间长 Transactional public void batchSave(Listdata list){ for(Data d : list){ mapper.insert(d); } }如果要求全部成功全部失败保留事务。如果允许部分失败去掉外层大事务分批提交捕获异常。三、经典业务场景1.下单主业务失败希望错误日志一定要落库日志不能回滚 REQUIRES_NEW内层异常必须 try‑catch。2.一个大事务里面某个子步骤失败只回滚子步骤外层可以继续提交外层失败全部回滚 NESTED 嵌套事务3.查询接口外层有事务就参与事务没有事务就直接查询 SUPPORTS4.内部更新方法强制调用者必须开启事务否则直接报错防止漏事务 MANDATORY5.批量导入几万条数据不想长事务外层有事务要挂起 NOT_SUPPORTED四、坑点1. 传播机制生效前提方法必须是外部调用不能本类内部调用A 类的 a () 方法调用本类的 b ()b 上 Transactional 传播机制完全失效因为不走 AOP 代理对象。要注入自己或者拆分成不同 Service。2.REQUIRES_NEW 一定要捕获内层异常。如果 REQUIRES_NEW 方法抛出异常没有 catch异常向上抛外层事务依然会标记回滚。内层事务已经回滚外层也回滚。3. NESTED 底层是 JDBC savepointMybatisMySQL InnoDB 可用分布式 JTA 环境不支持。4.REQUIRES_NEW 会挂起事务占用数据库连接大量使用会消耗连接池不要滥用。