大事务拆成小事务是基于数据库底层机制的关键调优手段，可显著缩短锁持有时间、提升连接复用率、降低回滚成本，从而提高吞吐量；需兼顾业务原子性、合理批次大小（100–500条）、显式提交及配套技术协同优化。
大事务拆成小事务，不是简单“切开”而已，而是从数据库底层运行机制出发的关键调优手段。它直接影响锁持有时间、连接占用周期、回滚成本和并发能力——这些直接决定吞吐量上限。
为什么大事务会拖垮吞吐量？
一个执行5秒的转账事务（比如批量扣款+记账+发通知），会持续持有行锁或表锁，阻塞其他事务读写同一数据段；同时占住数据库连接不释放，连接池迅速耗尽；若中途失败，还要回滚大量已执行操作，加重日志压力和恢复时间。这就像一条单车道上堵了一辆超长货车，后面所有车都动不了。
小事务如何实质性提升吞吐量？
把1000条记录的批量更新拆成20批、每批50条，效果体现在三个层面：
- 锁粒度大幅缩短：每批只锁几十行，锁等待时间从秒级降到毫秒级，其他事务几乎感知不到阻塞
- 连接复用率提高：每批执行完立刻提交并归还连接，连接池可支撑更多并发请求
- 失败影响范围可控：某一批出错，只需重试该批，而非整千条全部重来，系统恢复更快
实际拆分时必须注意的关键点
不是“越小越好”，需平衡事务边界与业务语义：
立即学习“Java免费学习笔记（深入）”；
- 同一批内操作必须满足业务原子性——例如“用户积分扣除+流水记录”不能拆开，否则出现扣了分但没记账的中间态
- 批次大小建议控制在100–500条之间（具体看单条SQL复杂度），避免过小导致网络/事务开销反超收益
- 使用显式 commit而非自动提交，确保每批真正落地；避免在循环内频繁开启/关闭事务上下文
- 若涉及跨库或分布式场景，小事务仍需配合最终一致性方案（如本地消息表+补偿），不能仅靠拆分解决全局一致性
配套技术能放大拆分效果
单纯拆事务只是基础，结合以下手段才能释放全部潜力：
- 连接池配置调优：增大 maxPoolSize + 缩短 connectionTimeout，匹配高频短事务节奏
- 批量SQL支持：用 PreparedStatement.addBatch() + executeBatch()，减少网络往返
- 异步化非核心步骤：如发送通知、写审计日志等移出事务体，用消息队列解耦
- 监控拆分实效：观察 avg transaction time、lock wait time、connection wait count 等指标是否同步下降
