哥们儿，3000万条数据要清，每万条半小时还报错，这确实够头疼的。我给你几个实战过的替代方案，你可以根据自己的业务场景和服务器情况选：

方案一：优化分批删除逻辑（最稳妥的增量方案） #

你之前循环分批删除报错，大概率是因为每次删除都全表扫描、锁冲突或者batch_size设置不合理。试试用主键/唯一索引分页的方式，避免全表扫描：

DO $$
DECLARE
  batch_size INT := 5000; -- 可根据服务器负载调小，比如2000-5000
  deleted_rows INT := batch_size;
BEGIN
  WHILE deleted_rows = batch_size LOOP
    -- 用主键/唯一索引列限定批次，避免每次扫全表
    DELETE FROM your_table
    WHERE id IN (
      SELECT id FROM your_table
      WHERE <你的删除条件>
      LIMIT batch_size
    );
    COMMIT;
    GET DIAGNOSTICS deleted_rows = ROW_COUNT;
    -- 加个小延迟，避免打满CPU/IO（可选）
    PERFORM pg_sleep(0.1);
  END LOOP;
END $$;

关键注意点：

• 确保删除条件列或分页用的id列有索引，不然子查询还是会全表扫描，速度快不起来
• 如果没有主键，用带唯一约束的列也行；实在没辙可以用ctid，但不推荐，因为ctid会随数据变更改变
• 降低batch_size，比如从10000降到5000，减少单次删除的锁持有时间，避免锁冲突报错

方案二：创建新表迁移保留数据（最快的方案，适合大批次删除） #

PostgreSQL的DELETE是单条标记删除，还要维护索引，大批次删除效率极低。反而把要保留的数据导到新表，再替换原表的速度快得多：

1. 创建新表并导入保留数据：

-- 注意：CREATE TABLE AS不会复制原表的索引、约束，后续需要手动补全
CREATE TABLE new_table AS
SELECT * FROM your_table
WHERE NOT <你的删除条件>;

2. 给新表补全索引、约束：
   比如原表的主键、外键、普通索引，都要在new_table上重新创建，避免业务异常。

3. 低峰期切换表（原子操作）：

BEGIN;
-- 原子重命名，确保切换过程中业务不中断
ALTER TABLE your_table RENAME TO old_table;
ALTER TABLE new_table RENAME TO your_table;
COMMIT;

4. 验证数据无误后删除旧表：

DROP TABLE old_table;

优缺点：

• 优点：速度比DELETE快10倍以上，几乎秒级完成数据迁移
• 缺点：需要足够的磁盘空间（至少等于原表大小），切换表时会有短暂锁，适合业务低峰期操作

方案三：利用分区表快速删除（适合按规则分区的表） #

如果你的表已经是分区表（比如按时间、地区分区），直接DROP对应分区就行，这是最快的方式：

DROP TABLE your_table_part_202301; -- 删除指定分区

如果还不是分区表，但以后经常有大批次删除需求，可以考虑把表改成分区表，后续删数据直接DROP分区，零成本操作。

方案四：调整数据库参数提升删除效率 #

配合上面的方案，临时调大PostgreSQL的内存参数，让删除操作有更多资源可用：

-- 会话级生效，重启后恢复默认值
SET maintenance_work_mem = '2GB'; -- 根据服务器内存调整，16G内存建议设2-4GB
SET work_mem = '64MB'; -- 提升排序、扫描的内存分配

最后必须提醒的点 #

• 操作前一定要全量备份数据！哪怕是测试环境，也别嫌麻烦
• 尽量在业务低峰期执行，避免影响正常业务
• 生产环境先在测试环境复现场景，验证方案没问题再上线

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