在PostgreSQL中直接执行一条DELETE语句清理上百万甚至上千万行记录，往往会让数据库在数分钟乃至数十分钟内持有表锁，阻塞正常的写入与查询，同时产生海量WAL日志并拖慢流复制。分批删除通过将大事务拆成多个小事务，既控制了单次锁的持有时间，也降低了回滚风险与磁盘压力。
为什么大批量DELETE会带来严重问题
当一条DELETE命中大量数据时，PostgreSQL需要在事务期间维护旧行版本，直到事务结束才清理。这意味着表与索引会被长时间锁定，其他会话的UPDATE、INSERT以及某些SELECT（如DDL前的锁等待）都可能被阻塞。对于高并发业务，这种长事务极易引发连接堆积与超时雪崩。
从存储与复制角度看，每一次删除都会写入WAL，数据量越大WAL膨胀越明显，物理备库重放日志的延迟也会同步拉大。如果中途失败回滚，已产生的清理动作虽能撤销，但WAL与IO开销无法收回。因此，把删除动作切分为可控批次，是运维侧的基础共识。
另一个隐性成本是死元组堆积。即便分批提交，若autovacuum来不及跟进，表膨胀依旧会发生。分批策略不仅要考虑每批行数，还要在批次之间留出vacuum窗口，或手动触发vacuum分析，避免空间无法复用。
基于主键游标的循环分批删除实现
最通用的做法是利用主键有序特性，每次删除一段连续区间。以下PL/pgSQL示例按每批五千行循环，直到目标区间清空。该方式依赖主键索引，定位快且锁时间短。
DO $$
DECLARE
v_min BIGINT;
v_max BIGINT;
v_batch INT := 5000;
v_last BIGINT;
BEGIN
SELECT min(id), max(id) INTO v_min, v_max FROM orders WHERE status = 'expired';
v_last := v_min;
WHILE v_last <= v_max LOOP
DELETE FROM orders
WHERE id >= v_last
AND id < v_last + v_batch
AND status = 'expired';
COMMIT;
v_last := v_last + v_batch;
PERFORM pg_sleep(0.1);
END LOOP;
END $$;
上述代码在每次循环后提交，单批失败仅丢失该批进度，不会整体回滚。pg_sleep用于让出IO带宽，避免从库延迟过高。若业务表主键非数字，可改用时间戳字段或唯一业务键，逻辑完全一致。
需要注意，DELETE中的WHERE条件必须覆盖批次边界与业务条件，否则会出现漏删或重复扫描。对于无主键堆表，可借助ctid分段，但ctid在vacuum后可能变化，不适合超长任务，仅适合短窗口一次性清理。
利用临时表与分区表优化删除效率
当需保留的数据远少于待删数据时，反向思路更高效：将需要留下的记录写入临时表，截断原表后再插回。这种方式把多次索引维护变成一次批量载入，代价是短暂停写。
CREATE TEMP TABLE keep_orders AS SELECT * FROM orders WHERE status <> 'expired'; TRUNCATE orders; INSERT INTO orders SELECT * FROM keep_orders;
该方案适合维护窗口，若不能停写则需结合逻辑复制或双写过渡。另一种更平滑的做法是分区表：按月份或哈希分区，直接DETACH旧分区并DROP，元数据操作几乎瞬间完成，且不产生大量WAL。
分区卸载示例：
ALTER TABLE orders DETACH PARTITION orders_2022_01; DROP TABLE orders_2022_01;
这种手段要求前期建模合理，但它把删除转化为字典操作，彻底规避了行级锁与死元组问题。对于日志类大表，分区是首选架构而非事后补救。
批次参数与监控的最佳实践
每批行数并非越小越好。过小会导致循环次数过多、事务开销累积；过大则锁时间回升。通常线上可从两千到一万行起步，观察pg_stat_activity中的锁等待与pg_stat_replication延迟动态调整。
建议在任务期间定时查询pg_locks与pg_stat_user_tables确认死元组与索引扫描成本。若发现某索引明显拖慢删除，可临时禁用非关键索引，批后重建。同时设置statement_timeout防止单批意外挂起。
最终落地时，应将分批脚本封装为可重入任务，记录已处理位点，保证中断后能从断点继续，而不是每次全量重扫。这样才能在业务无感前提下，安全消化历史数据包袱。
PostgreSQL分批删除锁表优化修改时间：2026-08-16 17:18:32