Django+PostgreSQL原子事务先存后验的数据库性能影响问询

原流程（先验证后保存）：

# 此处包含冗长复杂的验证逻辑，用于检查提交数据是否有效，涉及大量计算与查询。

with transaction.atomic():
    # 保存提交的数据

修改后的流程（先保存到事务再验证，失败回滚）：

def saved_data_is_valid():
    # 一些简短简单的计算。

...

# 跳过保存前的验证。
with transaction.atomic():
    # 在数据库中保存提交的数据但不提交。
    if not saved_data_is_valid():
        raise Exception("触发异常以回滚事务")

在AUTOVACUUM已开启、default_transaction_isolation为read committed、提交数据大多有效的前提下，想了解修改后产生的死行对数据库的性能损耗。

结合你的场景，这种方式产生的死行带来的性能影响非常有限，具体可以从以下几个维度看：

1. 死行的产生与堆积量 #

只有验证失败的事务才会产生死行——也就是你插入到事务中的记录，在回滚后会变成死行。由于你提到大部分提交数据有效，死行的总量会很低，不会出现大规模堆积的情况。

2. AUTOVACUUM的清理开销 #

开启AUTOVACUUM后，数据库会自动定期扫描表，清理死行并回收存储空间。因为死行量少，AUTOVACUUM的清理操作只会占用极少的CPU和IO资源，不会对正常业务造成明显影响。

• 注意：如果短时间内集中出现大量验证失败的情况，AUTOVACUUM可能会临时增加扫描频率，但这种场景在你的“大多有效”前提下几乎不会发生。

3. 对查询性能的影响 #

在read committed隔离级别下，PostgreSQL的查询会自动跳过死行，不会读取这些无效数据。只有当死行堆积导致表严重膨胀（数据页数量大幅增加）时，才会让查询需要扫描更多页面，影响性能。但你的场景中死行量少，再加上AUTOVACUUM的及时清理，表膨胀的概率极低，因此查询性能几乎不受影响。

4. 事务ID与冻结相关的开销 #

回滚的事务也会消耗事务ID，但PostgreSQL的事务ID是循环复用的，AUTOVACUUM在清理死行的同时也会处理事务ID冻结操作，防止ID耗尽。只要不是高频次的回滚（你的场景不满足），这部分开销可以忽略不计。

反过来想，你的新流程跳过了前置的冗长复杂验证逻辑，这部分原本需要大量计算和查询的开销被直接节省了——对于大部分有效提交来说，这是非常可观的性能提升。相比之下，少量死行带来的清理成本几乎可以忽略，整体上新流程的性能表现会优于原流程。

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