在后端业务系统里，SQL事务边界的划分直接决定了数据是否会出现错乱。不少团队在写代码时，要么把所有操作都裹进一个大事务，要么随意提交零散语句，结果在高并发下频繁出现库存超卖、账户余额不对等问题。事务边界的本质，是要回答“哪一些SQL必须作为一个不可分割的整体成功或失败”。如果这个问题没想清楚，再强的数据库也救不了业务逻辑上的漏洞。
从业务语义识别真正的原子操作
划分事务边界的第一步，不是看代码方便与否，而是看业务上哪些动作具备“同生共死”的属性。比如在电商下单场景中，用户付钱后，系统要生成订单记录、扣减商品库存、扣减账户余额。这三件事如果只做了其中两件，就会产生资损或超卖。因此它们必须放在同一个数据库事务里，要么全部提交，要么全部回滚。
但像发送通知短信、增加用户积分、写操作日志这类动作，并不参与核心资金或库存流转，它们失败不应导致下单主流程回滚。如果强行塞进同一个事务，一旦短信网关超时，整个下单事务被挂起，数据库连接长时间占用，后续请求全部阻塞。正确做法是把核心写操作作为短事务边界，非核心动作通过消息队列异步执行，实现最终一致。
我们可以用一个简单对照来理清边界。下面这段代码展示了错误的大事务写法：
// 错误示例：把无关操作放进同一事务
@Transactional
public void createOrderWrong(Order order) {
orderMapper.insert(order); // 写订单
stockMapper.deduct(order.getSku()); // 扣库存
pointMapper.add(order.getUserId()); // 加积分
smsService.send(order.getPhone()); // 发短信，可能超时
}
上面代码中smsService.send若网络抖动，事务无法提交，订单和库存变更也跟着卡住。改进方式是只保留前两个操作为事务边界，其余拆出：
@Transactional
public void createOrderRight(Order order) {
orderMapper.insert(order);
stockMapper.deduct(order.getSku());
// 提交后发事件
applicationEventPublisher.publishEvent(new OrderCreatedEvent(order));
}
利用隔离级别与锁机制守住边界
即便划好了原子操作，事务边界内仍可能因隔离级别不当而出现一致性问题。以MySQL默认的REPEATABLE READ为例，普通查询不会看到别的事务未提交数据，但更新操作会使用当前读并加行锁。如果边界内先查询库存再扣减，两个并发事务可能都读到旧值，造成超扣。此时需要在查询时显式加锁，如SELECT ... FOR UPDATE，把边界内的读取也纳入锁控制。
另一种常见误区是以为加了事务就不会丢更新。实际上如果边界跨越了远程服务调用，本地事务提交后远程失败，数据已经不一致。这时单库事务边界已不够用，要引入补偿事务或分布式事务框架。但多数中小型系统不必上Seata这类重方案，用本地消息表即可：本地事务写业务数据和消息表，另一线程轮询消息表投递，失败重试，保证最终一致。
下面的表对比了不同边界策略下的表现：
| 边界划分方式 | 一致性保障 | 并发影响 |
|---|---|---|
| 全量大事务 | 强一致但易失败 | 锁持有久，吞吐低 |
| 核心短事务+异步 | 核心强一致，外围最终一致 | 锁时间短，性能好 |
| 跨服务单事务 | 易不一致 | 依赖补偿 |
用显式控制与补偿机制兜住异常
很多ORM框架默认自动提交，开发者没意识到一条SQL就是一个边界。在复杂页面里，多次更新若不在同一显式事务中，中途报错前面已提交，后面没执行，数据就歪了。应当用begin transaction明确开启，在业务终点统一commit或rollback。例如在存储过程或脚本中手动控制：
START TRANSACTION; UPDATE accounts SET balance = balance - 100 WHERE id = 1; UPDATE accounts SET balance = balance + 100 WHERE id = 2; -- 若应用层检查失败则 ROLLBACK; 否则 COMMIT; COMMIT;
当边界不得不跨系统，补偿设计是关键。比如扣库存成功但订单落库失败，应记录补偿日志，定时任务把库存加回去。这种思路比追求实时强一致更贴合工程现实。边界划分不是越大约好，也不是越小越安全，而是贴合业务失败域，让该回滚的回滚，该重试的重试。
总结来说，SQL事务边界划分要先找业务原子单元，再用短事务包住核心写，外围解耦；配合合适隔离级别与显式锁，跨边界用消息与补偿。这样才能在复杂场景里稳稳保住数据一致性。