不能加事务的场景

一、Transactional 传播行为重点 3 种1. REQUIRED默认规则当前有事务就加入没有就新建事务所有操作共享同一个事务。场景绝大多数普通增删改单业务流程数据一致性保障。特点同一事务内任意节点异常整体回滚。2. REQUIRES_NEW规则强制新建独立事务挂起当前已有事务互不影响。特点1.内层事务提交 / 回滚不会影响外层事务2.外层异常回滚内层已提交的数据保留。适用日志记录、独立埋点、必须落库的操作哪怕主业务失败。3. NOT_SUPPORTED你标注的无事务运行规则强制以非事务方式运行如果上层存在事务会先挂起原有事务。特点方法内所有 DB 操作自动提交异常不会回滚。适用查询操作、大数据量遍历、外部接口调用场景。代码示例importorg.springframework.transaction.annotation.Propagation;importorg.springframework.transaction.annotation.Transactional;// 默认 REQUIREDTransactionalpublicvoidnormalBiz(){// 增删改整体事务}// 新建独立事务Transactional(propagationPropagation.REQUIRES_NEW)publicvoidseparateLog(){// 独立事务不受外层事务影响}// 无事务运行Transactional(propagationPropagation.NOT_SUPPORTED)publicvoidqueryOrCallOuter(){// 查询/调用第三方接口无事务}二、不建议开启事务的场景补充原因 避坑1.外部接口调用 批量 DB 操作原因接口调用网络耗时不确定会造成长事务锁表、占用数据库连接、引发死锁、超时。方案拆分为「先调用接口 → 再分批操作数据库」DB 部分分批小事务。2.大数据量 / 高频率定时任务原因全量数据放在一个事务中事务体积过大日志暴涨、回滚代价极高、容易事务超时。方案关闭全局事务NOT_SUPPORTED分页 / 分批处理每批单独开小事务。3.额外补充禁忌场景纯查询接口没必要开启事务增加开销直接用NOT_SUPPORTED。循环内单次少量操作长循环套大事务极易长事务。三、事务作用域 生效范围核心结论Spring 事务仅对当前方法内的 INSERT / DELETE / UPDATE 生效查询SELECT本身不参与事务回滚逻辑。边界说明事务锁、数据回滚、隔离级别只作用于被修改的数据表 / 行不同库、不同表、跨库操作默认无法统一事务普通单库事务不支持跨库。常见误区误区加了事务整个服务所有表都会被锁定。纠正仅本次增删改涉及的表 / 行受事务管控。四、注意事项1.事务失效经典场景同类内部调用A方法(无事务)直接调用本类Transactional B方法→事务失效AOP 动态代理拦截不到。方法非publicprivate/protected 方法加注解 → 事务失效。异常类型默认只捕获 RuntimeException/Error检查型 Exception 不回滚。解决Transactional(rollbackFor Exception.class)2.NOT_SUPPORTED 注意点上层有事务时进入该方法原事务被挂起方法执行完再恢复原事务方法内报错数据不会回滚。3.REQUIRES_NEW 注意点嵌套使用会产生事务挂起 / 恢复数据库开销更大不要滥用。