@transaction.atomic 便宜吗？答案

【问题标题】：Is @transaction.atomic cheap?@transaction.atomic 便宜吗？
【发布时间】：2021-12-19 10:02:24
【问题描述】：

这主要是出于好奇，但是用@transaction.atomic 包裹整个视图的 DB 惩罚可以忽略不计吗？

我正在考虑表单的 GET 或其在验证失败后重新显示涉及处理查询集的视图。（例如，ModelChoiceFields，或获取模板显示的对象。）

在我看来，在代码块周围使用with transaction.atomic() 似乎要自然得多，只有在用户的输入经过验证后才会实际更改一堆相关的 DB 对象。

我错过了什么吗？

【问题讨论】：

是的，最好使事务尽可能小（数据库服务器有性能成本）。这在 documentation 中标题为“性能注意事项”的注释中提到（您需要滚动到链接部分的底部才能找到该注释）
谢谢。没有发现这个。它说“打开的事务对您的数据库服务器有性能成本。为了最大限度地减少这种开销，请让您的事务尽可能短。如果您在 Django 请求之外的长时间运行的进程中使用 atomic() ，这一点尤其重要/响应周期。”。在实际上不写入数据库的视图期间找不到任何短期事务影响的迹象，这正是我想知道的。

标签： django database django-models

【解决方案1】：

来自源代码：

def atomic(using=None, savepoint=True, durable=False):
    # Bare decorator: @atomic -- although the first argument is called
    # `using`, it's actually the function being decorated.
    if callable(using):
        return Atomic(DEFAULT_DB_ALIAS, savepoint, durable)(using)
    # Decorator: @atomic(...) or context manager: with atomic(...): ...
    else:
        return Atomic(using, savepoint, durable)

都是一样的。在这两种情况下，该函数都返回一个 Atomic 对象，该对象处理事务是否应该提交。

【讨论】：

我的意思是，创建事务不会导致数据库本身在创建和提交之间减速吗？回滚能力不能免费，但便宜吗？
这家伙解释得很好。 youtube.com/watch?v=omizQEkTcl4