事务边界应按业务原子性划分，每个业务动作（如“用户下单”）对应一个事务；避免跨库/服务操作破坏一致性，优先用最终一致性+补偿机制；须配套超时控制、日志追踪与对账兜底。
事务边界划分的核心是“一个业务操作对应一个事务”，不是按SQL语句数量，也不是按函数调用层次，而是看是否满足原子性需求：要么全部成功，要么全部回滚，中间状态对外不可见。
从业务用例出发识别事务边界
每个明确的业务动作（如“用户下单”“账户转账”“库存扣减并生成订单”）应封装为独立事务。不能把“查余额→校验→扣款→记日志→发消息”拆成多个事务，否则会出现余额已扣但订单未生成、或订单生成但扣款失败等不一致情况。
- 典型反例：在Web接口中，先执行UPDATE account SET balance = balance - 100 WHERE id = 1，再调用另一个服务扣库存，两个操作不在同一事务内 → 账户扣了但库存没扣，或反之
- 正确做法：把所有关联数据变更（含主库写、关联表更新、必要状态标记）放在同一个数据库事务内完成；跨系统操作（如发MQ、调第三方API）应放在事务提交后，通过可靠消息或本地消息表补偿
避免事务过长或嵌套导致的问题
事务持有数据库锁的时间越长，并发性能越差，死锁风险越高。尤其要警惕在事务中做耗时操作（如HTTP请求、文件读写、复杂计算）。
- 读操作尽量不进事务：SELECT查询若不参与写逻辑，无需包裹在BEGIN/COMMIT中
- 不要在事务内调外部服务：比如在事务中调用微信支付接口，一旦网络超时，事务卡住，连接池可能被耗尽
- 禁止应用层“伪嵌套事务”：MySQL不支持真正的嵌套事务，SAVEPOINT仅是回滚点，不能替代事务隔离；Spring的@Transactional(propagation = REQUIRES_NEW)会挂起当前事务新建一个，需谨慎使用，避免破坏业务一致性语义
多数据源或分库场景下的事务处理
单机单库可用本地事务保证ACID；一旦涉及多个数据库实例（如订单库+用户库）、微服务拆分、或读写分离从库，本地事务失效，必须升级为分布式事务方案。
- 优先考虑业务妥协：例如“下单成功但支付异步通知”，用最终一致性代替强一致，配合对账与补偿
- 技术选型按场景分级：TCC（适合核心链路可控）、Saga（适合长流程）、Seata AT模式（侵入小，依赖undo_log，需注意大字段和DDL限制）
- 关键原则：不因技术便利牺牲一致性。例如用“本地消息表+定时扫描”比直接往两个库写更可靠，因为消息表和主业务在同一事务，确保至少投递一次
事务设计必须配套可观测与兜底机制
再严谨的事务逻辑也需应对异常：数据库宕机、网络分区、代码Bug、人为误操作。不能只靠BEGIN/COMMIT完事。
- 记录事务上下文日志：包含traceId、业务单号、涉及主键、开始/结束时间、是否回滚，便于问题定位
- 设置合理超时：JDBC的queryTimeout、Spring的@Transactional(timeout = 30)防止事务长期挂起
- 建立定期核对机制：如每日比对订单表与支付流水表金额是否平衡，发现不一致立即告警并触发人工或自动修复流程
