Spanner最佳实践：多小事务还是少合并事务？

针对你的场景，优先选择选项a（多单操作事务：先通过只读事务查询，再在独立事务中添加缺失记录）更符合Spanner的最佳实践，核心原因结合Spanner的事务特性分析如下：

• 充分利用只读事务的低开销优势
  Spanner的只读事务是无锁快照读，不需要持有任何写锁，也不会与其他读写事务产生冲突，性能开销极低。你的场景中，大部分操作可能是“读取已存在的重复信息”，用只读事务就能完成，完全不需要启动代价更高的读写事务。

• 最小化读写事务的锁竞争风险
  选项b的合并读写事务需要在查询阶段就持有目标行的锁直到事务提交，若多个请求同时针对同一账户的重复信息表操作，很容易引发锁竞争，导致事务延迟甚至中止（abort）。拆分后，只有确认需要追加记录时才启动单行读写事务，锁持有时间极短，并发冲突的概率大幅降低。

• 适配Spanner的事务成本模型
  Spanner的计费与事务类型、持续时间、涉及行数强相关，只读事务的成本远低于读写事务。拆分事务后，能减少不必要的读写事务数量，降低整体使用成本，同时也能提升系统的吞吐量。

特殊场景补充 #

如果你的业务要求绝对避免重复插入（极端情况下，两次只读查询之间有其他事务插入了目标记录），可以考虑使用Spanner的INSERT ... ON CONFLICT语句（需为重复信息表设置唯一键），或者用单行读写事务做查询+插入。但对于你描述的“单账户每日最多5条记录、每日更新数次”的场景，这种极端并发的概率极低，优先选择拆分事务的方案更稳妥。

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