按ID删除数百万行的最佳方法

Question 1

我需要从PG数据库中删除大约200万行。我有一个需要删除的ID列表。但是，我尝试执行此操作的任何方法都需要花费几天的时间。

我尝试将它们放在一个表中并按100个批次进行处理。4天后，它仍在运行，仅删除了297268行。（我必须从ID表中选择100个ID，删除该列表中的位置，从ID表中删除我选择的100个ID）。

我试过了：

DELETE FROM tbl WHERE id IN (select * from ids)

这也是永远的。难以估计需要多长时间，因为直到完成我才能看到它的进度，但是查询在2天后仍在运行。

当我知道要删除的特定ID且有数百万个ID时，这只是一种寻找从表中删除的最有效方法。

Question 2

一切取决于...

删除所有索引（删除ID上需要删除的索引除外）
，然后重新创建它们（比对索引进行增量更新要快得多）
检查是否有可以安全地暂时删除/禁用的触发器
外键是否引用您的表？可以删除它们吗？暂时删除？
根据您的自动真空设置，可能有助于VACUUM ANALYZE在操作之前运行。
假设没有对相关表的并发写访问权，或者您可能必须专门锁定表，或者此路由可能根本不适合您。
根据您的设置，《填充数据库》手册相关章节中列出的某些要点也可能有用。
如果删除表的大部分，其余部分放入RAM，最快和最简单的方法是：

SET temp_buffers = '1000MB'; -- or whatever you can spare temporarily

CREATE TEMP TABLE tmp AS
SELECT t.*
FROM   tbl t
LEFT   JOIN del_list d USING (id)
WHERE  d.id IS NULL;      -- copy surviving rows into temporary table

TRUNCATE tbl;             -- empty table - truncate is very fast for big tables

INSERT INTO tbl
SELECT * FROM tmp;        -- insert back surviving rows.

这样，您不必重新创建视图，外键或其他依赖对象。阅读temp_buffers手册中的设置。只要表适合内存，或者至少适合大多数内存，此方法就会很快。请注意，如果服务器在此操作过程中崩溃，则可能会丢失数据。您可以将所有内容包装到事务中以使其更安全。

ANALYZE之后运行。或者，VACUUM ANALYZE如果您没有采用截断路线，或者VACUUM FULL ANALYZE您希望将其最小化。对于大表，请考虑备选方案CLUSTER/ pg_repack：

优化Postgres时间戳查询范围

对于小型表，通常使用简单DELETE而不是TRUNCATE更快的方法：

DELETE FROM tbl t
USING  del_list d
WHERE  t.id = d.id;

阅读手册中的“注释”部分TRUNCATE。特别是（如Pedro在其评论中也指出的那样）：

TRUNCATE不能在具有来自其他表的外键引用的表上使用，除非所有这些表在同一命令中也被截断。[...]

和：

TRUNCATE不会ON DELETE触发表可能存在的任何触发器。

Question 3

我们知道PostgreSQL的更新/删除性能不如Oracle强。当我们需要删除数百万或数以千万计的行时，这确实很困难并且需要很长时间。

但是，我们仍然可以在生产数据库中执行此操作。以下是我的想法：

首先，我们应该创建一个包含两列的日志表- id＆flag（id指您要删除的ID；flag可以是Y或null，Y表示记录已成功删除）。

稍后，我们创建一个函数。我们每10,000行执行一次删除任务。您可以在我的博客上看到更多详细信息。尽管它是中文，但是您仍然可以从那里的SQL代码获取所需的信息。

确保id两个表的列都是索引，因为它将更快地运行。

Question 4

您可以尝试将表中要删除的ID之外的所有数据复制到新表中，然后重命名然后交换表（前提是您有足够的资源来执行此操作）。

这不是专家建议。

Question 5

两个可能的答案：

当您尝试删除记录时，您的表可能具有很多约束或触发器。这将导致很多处理器周期和从其他表进行检查。
您可能需要将此语句放入事务中。

Question 6

首先，请确保您要删除的表以及用于删除ID的表的ID字段都有索引。

一次100个似乎太小。尝试1000或10000。

无需从删除ID表中删除任何内容。为批次号添加一个新列，并为批次1填充1000，为批次2填充1000，以此类推，并确保删除查询中包含批次号。

Question 7

最简单的方法是删除所有约束，然后删除。

Question 8

我自己碰到了这个问题，到目前为止，最快的方法是将WITH Queries与结合使用

基本上，WITH查询创建一个临时表，该表具有要在其中要删除的表中删除的主键。

WITH to_delete AS (
   SELECT item_id FROM other_table WHERE condition_x = true
)
DELETE FROM table 
USING to_delete 
WHERE table.item_id = to_delete.item_id 
  AND NOT to_delete.item_id IS NULL;

当然，SELECTWITH查询的内部可以与具有多个联接等的任何其他选择一样复杂。它仅需要返回一个或多个列，这些列用于标识目标表中需要删除的项目。

注意：AND NOT to_delete.item_id IS NULL很有可能不是必需的，但是我不敢尝试。

其他要考虑的是

通过外键在引用该表的其他表上创建索引。在某些情况下，这可以将删除工作从几小时减少到几秒钟
延迟约束检查：目前还不清楚有多少，如果任何改善，这达到，但根据这个可以提高性能。不利的一面是，如果您遇到外键违规，您只会在最后一刻才学会它。
危险，但可能会大大提高：在删除过程中禁用约束检查和触发器

Question 9

如果您要从中删除的表被引用some_other_table（并且您甚至不想暂时删除外键），请确保在！的引用列上有索引some_other_table。

我有一个类似的问题，并auto_explain与一起使用auto_explain.log_nested_statements = true，它显示delete实际在上执行seq_scans some_other_table：

    Query Text: SELECT 1 FROM ONLY "public"."some_other_table" x WHERE $1 OPERATOR(pg_catalog.=) "id" FOR KEY SHARE OF x    
    LockRows  (cost=[...])  
      ->  Seq Scan on some_other_table x  (cost=[...])  
            Filter: ($1 = id)

显然，它试图锁定另一个表中的引用行（该行不应该存在，否则删除将失败）。在引用表上创建索引后，删除速度提高了几个数量级。