PostgreSQL中事务批量删大量行是否有影响？分批次删除更安全吗？

一、Delete 对 Select 的影响 #

PostgreSQL 中，DELETE 会给待删除的行加上排他锁（Row Exclusive Lock），但这不会影响普通 SELECT 查询——因为PostgreSQL默认隔离级别是READ COMMITTED，SELECT只会读取事务提交前的数据快照，不会被未提交的DELETE阻塞。

不过有两种特殊情况需要留意：

• 如果SELECT使用了FOR UPDATE/FOR SHARE这类加锁查询，刚好命中被DELETE锁定的行，就会被阻塞，直到DELETE事务提交或回滚。
• 当DELETE涉及大量行且触发ON DELETE CASCADE时，数据库需要扫描关联表处理级联删除，会产生大量IO和事务日志，可能间接拖慢整体查询性能，比如挤占CPU、IO资源。

二、是否需要拆分删除事务 #

非常有必要，尤其是你的场景允许延迟删除的情况下，拆分小事务有这些核心优势：

1. 缩短锁持有时间：每次只删1000行，事务执行时长大幅缩短，排他锁的持有时间也随之减少，就算出现锁冲突，影响范围和时长也会降到最低。
2. 规避长事务风险：大事务会占用更多数据库资源，还可能导致VACUUM无法及时清理死元组，引发表膨胀；拆分后每个小事务提交后，VACUUM可以及时回收空间。
3. 平缓级联删除的负载冲击：一次性批量级联删除大量数据时，可能触发关联表的大规模删除操作，拆分后每次处理的关联数据量小，对数据库的负载影响更平缓。

你给出的拆分写法是可行的，还可以优化得更高效，比如直接用LIMIT过滤，避免子查询：

DELETE FROM table_a
WHERE timestamp < certain_time
LIMIT 1000;

可以把这段逻辑放到循环里，直到返回的受影响行数为0，就完成了所有符合条件的删除。另外建议在业务低峰期执行这类批量删除任务，进一步降低对正常业务的影响。

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