SpringBoot+MyBatis事务控制实战：从默认行为到精细化手动管理
1. SpringBoot+MyBatis事务的默认行为解析
第一次在SpringBoot项目中使用MyBatis时，我发现一个有趣的现象：明明没有显式开启事务，数据库操作却自动运行在事务中。后来通过日志分析才明白，这是SpringBoot的默认行为。就像我们去餐厅吃饭，服务员默认会给每位顾客倒上一杯水，不需要特别说明。
在单元测试中，这个特性尤为明显。比如下面这段测试代码：
@SpringBootTest public class UserServiceTest { @Autowired private UserMapper userMapper; @Test public void testInsert() { User user = new User("张三", 25); userMapper.insert(user); System.out.println("插入完成"); } }运行时会发现控制台打印了"Began transaction"的日志。这就像魔术师在表演前悄悄布置好了机关，观众还没察觉，表演就已经开始了。
事务的默认传播行为是PROPAGATION_REQUIRED，意思是如果当前没有事务就新建一个，如果已经存在事务就加入其中。这种设计很贴心，就像智能家居系统，当你晚上回家时，灯光会自动亮起，不需要手动开关。
2. 单元测试中的事务陷阱与解决方案
2.1 测试中的事务干扰问题
在实际项目中，我踩过一个坑：测试数据"凭空消失"。明明测试用例执行成功了，数据库里却找不到刚插入的数据。后来发现是因为测试方法默认在事务中运行，测试结束后事务回滚了。
这就像用铅笔在笔记本上写字，测试时写的内容（事务中的操作）在合上笔记本（测试结束）后自动消失了（回滚）。要保留这些笔记，我们需要特别说明：
@Test @Rollback(false) public void testPersistData() { // 测试代码 }或者在类级别加上注解：
@SpringBootTest @Transactional(propagation = Propagation.NOT_SUPPORTED) public class NoTransactionTest { // 测试方法 }2.2 事务传播行为的七种武器
Spring提供了丰富的事务传播行为选项，就像瑞士军刀的不同工具：
- REQUIRED（默认）：有事务就加入，没有就新建
- SUPPORTS：有事务就加入，没有也无所谓
- MANDATORY：必须要有事务，否则抛异常
- REQUIRES_NEW：新建事务，挂起当前事务
- NOT_SUPPORTED：非事务方式执行，挂起当前事务
- NEVER：必须在非事务环境下执行，否则抛异常
- NESTED：嵌套事务
在测试环境中，NOT_SUPPORTED就像关闭自动保存功能，让每次操作立即生效：
@Test @Transactional(propagation = Propagation.NOT_SUPPORTED) public void testRealTimeInsert() { // 每次插入都会立即提交 }3. 手动事务控制的进阶技巧
3.1 PlatformTransactionManager实战
有时候我们需要更精细地控制事务，就像手动挡汽车比自动挡更有操控感。Spring的PlatformTransactionManager就是我们的换挡杆：
@Autowired private PlatformTransactionManager transactionManager; public void batchInsertWithManualControl(List<User> users) { DefaultTransactionDefinition def = new DefaultTransactionDefinition(); def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW); for (User user : users) { TransactionStatus status = transactionManager.getTransaction(def); try { userMapper.insert(user); transactionManager.commit(status); } catch (Exception e) { transactionManager.rollback(status); throw e; } } }这种手动控制方式特别适合批量操作，可以避免一个失败导致全部回滚，就像搬家时分开打包物品，一个箱子损坏不会影响其他箱子。
3.2 事务隔离级别的选择
不同的业务场景需要不同的事务隔离级别，就像不同的天气要穿不同的衣服：
| 隔离级别 | 脏读 | 不可重复读 | 幻读 | 适用场景 |
|---|---|---|---|---|
| READ_UNCOMMITTED | ✓ | ✓ | ✓ | 几乎不用 |
| READ_COMMITTED | × | ✓ | ✓ | 普通查询 |
| REPEATABLE_READ | × | × | ✓ | 财务系统 |
| SERIALIZABLE | × | × | × | 票务系统 |
在Spring中设置隔离级别：
@Transactional(isolation = Isolation.REPEATABLE_READ) public void updateAccountBalance() { // 业务逻辑 }4. 事务性能优化实战经验
4.1 连接池配置建议
事务性能与数据库连接池密切相关。经过多次压测，我总结出这些经验值：
# 推荐配置 spring.datasource.hikari.maximum-pool-size=20 spring.datasource.hikari.minimum-idle=5 spring.datasource.hikari.idle-timeout=30000 spring.datasource.hikari.max-lifetime=1800000连接池就像公司里的会议室，太少会影响效率，太多又浪费资源。根据我的经验，最大连接数设置为CPU核心数的2-3倍比较合适。
4.2 事务超时设置
长时间运行的事务会占用数据库资源，就像餐厅里占着桌子不点菜的顾客。我们可以设置超时时间：
@Transactional(timeout = 30) // 30秒超时 public void longRunningProcess() { // 复杂业务逻辑 }如果操作预计耗时较长，最好拆分成多个小事务，就像把大件行李分多次搬运。
5. 常见问题排查指南
5.1 事务不生效的六大原因
在帮助新手排查问题时，我发现这些常见陷阱：
- 方法不是public的
- 异常被catch没有抛出
- 同类方法调用（this.method()）
- 数据库引擎不支持（如MyISAM）
- 异常类型不是RuntimeException
- 注解被错误覆盖
这就像侦探破案，要逐一排查每个可能性。建议在配置中加入：
logging.level.org.springframework.transaction.interceptor=TRACE这样可以在日志中看到详细的事务决策过程。
5.2 分布式事务的替代方案
对于跨服务的事务需求，我通常建议使用最终一致性方案而非强一致性。比如：
- 本地消息表
- 事务消息（RocketMQ）
- Saga模式
- TCC模式
这就像跨国快递，与其要求所有包裹同时到达（强一致性），不如确保每个包裹最终都能送达（最终一致性）。
6. 最佳实践总结
经过多个项目的实战，我总结了这些经验法则：
- 保持事务短小精悍
- 避免在事务中进行远程调用
- 合理设置隔离级别
- 为只读操作添加@Transactional(readOnly=true)
- 异常处理要明确
- 监控事务执行时间
就像老司机分享的驾驶技巧，这些经验能帮你避开很多坑。特别是在高并发场景下，合理的事务设计能让系统性能提升数倍。
最后提醒一点：事务不是万能的，就像安全带不能防止所有交通事故。合理的架构设计、正确的索引、适当的缓存，这些都能减少对事务的依赖。在实际项目中，我通常会先考虑"是否可以不用事务"，而不是"如何用事务解决"。