Django中使用transaction.atomic()时.save()方法为何仍耗时？

你对transaction.atomic()的功能存在本质误解：该上下文管理器的作用是保证数据库操作的原子性，不会缓存块内的SQL语句到块结束才批量执行，你观察到的每次save()触发实时UPDATE、存在明确执行耗时是完全正常的框架表现，和PostgreSQL的行为也完全匹配。

具体机制说明 #

• 事务原子性不代表SQL延迟执行：进入atomic()块后，Django会立即在当前数据库连接上开启事务，关闭默认的自动提交逻辑。块内每一次save()调用，Django都会立刻构造对应的UPDATE语句发送给PostgreSQL，数据库会实时完成行匹配、行锁申请、内存页更新、WAL日志写入等操作，再把执行结果返回给Django。这些数据变更在事务提交前仅对当前连接可见，对其他事务完全隔离，但并非没有执行。
• 你统计的耗时是真实的操作开销：单次save()平均35ms的耗时，包含了Django模型序列化、SQL构造、客户端与数据库的网络往返、数据库执行UPDATE本身的成本，属于PostgreSQL单条主键更新的正常性能区间。你在调试日志中看到每次save()对应一条独立UPDATE，是框架的正常行为，不属于异常。
• atomic()的优化点是事务提交成本，而非SQL执行成本：Django默认开启自动提交，不使用atomic()时每执行完一条写SQL就会触发一次事务提交，提交过程需要强制将WAL日志刷入持久化存储，单次刷盘的开销往往远高于SQL本身的执行成本。atomic()会将块内所有操作的提交动作合并，仅在块正常执行完成后执行一次COMMIT，省去了多次刷盘的IO开销，但不会减少单条SQL的传输、执行成本。

常见认知误区 #

不要混淆「批量操作」和「事务」的作用边界：
如果你希望减少和数据库的交互次数、降低多次网络往返的开销，需要使用Django内置的批量操作接口，比如bulk_create、bulk_update，这类接口会将多条数据的变更合并为少量SQL语句一次性发送，属于SQL构造层的优化，和事务机制无关。

事务只解决操作的原子性、隔离性问题，不会改变单条SQL的发送、执行时机。

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