数据库保存选单事务批量还是多事务逐条保存的方案咨询

核心结论 #

两种方案没有绝对的优劣，匹配你的业务场景的就是最优解，核心差异可以从多个维度对比判断。

两个方案的核心差异 #

1. 性能表现 #

单事务方案的写入性能远超多事务方案，这也是大部分人优先考虑批量写入的核心原因。数据库每次提交事务都需要完成redo log刷盘、持久化确认等操作，假设你要写入1000条数据，多事务方案需要执行1000次事务提交的刷盘操作，单事务方案只需要执行1次，两者的吞吐量差2~3个量级都是正常情况，数据量越大性能差异越明显。

2. 故障影响范围 #

这是单事务方案的最大短板：只要任意一条条目保存失败，整个事务会全部回滚，之前所有已经执行的写入操作都会被撤销，你需要重新处理整批数据，还要额外处理重试的幂等问题。多事务方案下，单条条目写入失败只会回滚当前这条的事务，不会影响其他已经写入成功的条目，故障后只需要重试失败的单条即可。

3. 数据库锁与资源风险 #

单事务属于典型的长事务，事务执行过程中会持续占有用到的行锁、表锁资源，如果你写入的过程涉及索引更新、关联表查询，长事务会大幅提升锁冲突的概率，甚至会阻塞其他业务的写入请求，在高并发的生产共享库上要尤其警惕长事务带来的雪崩风险。同时如果单批次条目量极大（比如上万甚至几十万条），单事务生成的undo/redo日志会占用大量数据库内存、磁盘资源，严重时可能撑爆日志分区导致数据库实例故障。
多事务方案每个事务执行时间极短，锁持有时间短，锁冲突概率低，每次提交后就会释放日志资源，不会出现长事务相关的风险。

4. 实现复杂度 #

两者的实现复杂度基本持平，如果需要做错误重试，多事务方案的重试逻辑会更简单，只需要记录失败的条目id重试即可，不需要考虑整批重复写入的幂等问题。

选型建议 #

• 如果满足以下所有条件，优先选单事务批量写入：
  • 单批次条目量不大（建议<1000条，具体可根据你使用的数据库调整阈值），不会触发长事务告警
  • 业务允许整批失败全部回滚的影响，或者已经实现了整批重试的幂等逻辑
  • 对写入性能要求较高，数据库写入压力大
• 如果满足以下任意一个条件，优先选多事务逐条写入：
  • 业务要求单条写入失败不能影响其他正常条目，故障后不需要全量重试
  • 单批次条目量极大，单事务会导致长事务或者日志溢出
  • 部署的数据库是多业务共享的高并发实例，不能接受长事务带来的锁冲突风险

两种方案的伪代码参考 #

单事务方案 #

BeginTransaction()

for (int i = 0; i < items.Count; i++)
    items[i].Save();

CommitTransaction()

多事务方案 #

for (int i = 0; i < items.Count; i++)
{
  BeginTransaction()
  items[i].Save();
  CommitTransaction() 
}

内容的提问来源于stack exchange，提问作者Anthony