在运行非常缓慢的 SQL 的非常大的表上删除查询答案

【问题标题】：Delete query on a very large table running extremely slowly SQL在运行非常缓慢的 SQL 的非常大的表上删除查询
【发布时间】：2020-10-06 19:30:06
【问题描述】：

我有这个 SQL 查询：

delete from scans
    where scandatetime>(current_timestamp - interval '21 days') and
          scandatetime <> (select min(tt.scandatetime) from scans tt where tt.imb = scans.imb) and
          scandatetime <> (select max(tt.scandatetime) from scans tt where tt.imb = scans.imb)
;

我用来从下表中删除记录：

|imb        |scandatetime       |status   |scanfacilityzip|
+-----------+-------------------+---------+---------------+
|isdijh23452|2020-01-01 13:45:12|Intake   |12345          |
|isdijh23452|2020-01-01 13:45:12|Intake   |12345          |
|isdijh23452|2020-01-01 19:30:32|Received |12345          |
|isdijh23452|2020-01-02 04:50:22|Confirmed|12345          |
|isdijh23452|2020-01-03 19:32:18|Processed|45867          |
|awgjnh09864|2020-01-01 10:24:16|Intake   |84676          |
|awgjnh09864|2020-01-01 19:30:32|Received |84676          |
|awgjnh09864|2020-01-01 19:30:32|Received |84676          |
|awgjnh09864|2020-01-02 02:15:52|Processed|84676          |

这样每个 IMB 只保留 2 条记录，一条具有最短的 scandatetime 和最长的 scandatetime。我也对此进行了限制，因此它仅对不到 3 周的记录执行此操作。结果表如下所示：

|imb        |scandatetime       |status   |scanfacilityzip|
+-----------+-------------------+---------+---------------+
|isdijh23452|2020-01-01 13:45:12|Intake   |12345          |
|isdijh23452|2020-01-03 19:32:18|Processed|45867          |
|awgjnh09864|2020-01-01 10:24:16|Intake   |84676          |
|awgjnh09864|2020-01-02 02:15:52|Processed|84676          |

这个表有几个索引，有几千万行，所以查询通常需要很长时间才能运行。如何加快速度？

解释输出：

Delete on scans  (cost=0.57..115934571.45 rows=10015402 width=6)
  ->  Index Scan using scans_staging_scandatetime_idx on scans  (cost=0.57..115934571.45 rows=10015402 width=6)
        Index Cond: (scandatetime > (CURRENT_TIMESTAMP - '21 days'::interval))
        Filter: ((scandatetime <> (SubPlan 2)) AND (scandatetime <> (SubPlan 4)))
        SubPlan 2
          ->  Result  (cost=3.91..3.92 rows=1 width=8)
                InitPlan 1 (returns $1)
                  ->  Limit  (cost=0.70..3.91 rows=1 width=8)
                        ->  Index Only Scan using scans_staging_imb_scandatetime_idx on scans tt  (cost=0.70..16.79 rows=5 width=8)
                              Index Cond: ((imb = scans.imb) AND (scandatetime IS NOT NULL))
        SubPlan 4
          ->  Result  (cost=3.91..3.92 rows=1 width=8)
                InitPlan 3 (returns $3)
                  ->  Limit  (cost=0.70..3.91 rows=1 width=8)
                        ->  Index Only Scan Backward using scans_staging_imb_scandatetime_idx on scans tt_1  (cost=0.70..16.79 rows=5 width=8)
                              Index Cond: ((imb = scans.imb) AND (scandatetime IS NOT NULL))

表 DDL：

-- Table Definition ----------------------------------------------

CREATE TABLE scans (
    imb text,
    scandatetime timestamp without time zone,
    status text,
    scanfacilityzip text
);

-- Indices -------------------------------------------------------

CREATE INDEX scans_staging_scandatetime_idx ON scans(scandatetime timestamp_ops);
CREATE INDEX scans_staging_imb_idx ON scans(imb text_ops);
CREATE INDEX scans_staging_status_idx ON scans(status text_ops);
CREATE INDEX scans_staging_scandatetime_status_idx ON scans(scandatetime timestamp_ops,status text_ops);
CREATE INDEX scans_staging_imb_scandatetime_idx ON scans(imb text_ops,scandatetime timestamp_ops);

编辑：这是解释分析输出（注意，我将间隔更改为 1 天以使其运行更快）：

Delete on scans  (cost=0.58..3325615.74 rows=278811 width=6) (actual time=831562.877..831562.877 rows=0 loops=1)
  ->  Index Scan using scans_staging_scandatetime_idx on scans  (cost=0.58..3325615.74 rows=278811 width=6) (actual time=831562.875..831562.875 rows=0 loops=1)
        Index Cond: (scandatetime > (CURRENT_TIMESTAMP - '1 day'::interval))
        Filter: ((scandatetime <> (SubPlan 2)) AND (scandatetime <> (SubPlan 4)))
        Rows Removed by Filter: 277756
        SubPlan 2
          ->  Result  (cost=3.92..3.93 rows=1 width=8) (actual time=1.675..1.675 rows=1 loops=277756)
                InitPlan 1 (returns $1)
                  ->  Limit  (cost=0.70..3.92 rows=1 width=8) (actual time=1.673..1.674 rows=1 loops=277756)
                        ->  Index Only Scan using scans_staging_imb_scandatetime_idx on scans tt  (cost=0.70..16.80 rows=5 width=8) (actual time=1.672..1.672 rows=1 loops=277756)
                              Index Cond: ((imb = scans.imb) AND (scandatetime IS NOT NULL))
                              Heap Fetches: 277761
        SubPlan 4
          ->  Result  (cost=3.92..3.93 rows=1 width=8) (actual time=0.086..0.086 rows=1 loops=164210)
                InitPlan 3 (returns $3)
                  ->  Limit  (cost=0.70..3.92 rows=1 width=8) (actual time=0.084..0.085 rows=1 loops=164210)
                        ->  Index Only Scan Backward using scans_staging_imb_scandatetime_idx on scans tt_1  (cost=0.70..16.80 rows=5 width=8) (actual time=0.083..0.083 rows=1 loops=164210)
                              Index Cond: ((imb = scans.imb) AND (scandatetime IS NOT NULL))
                              Heap Fetches: 164210
Planning Time: 11.360 ms
Execution Time: 831562.956 ms

编辑：解释分析缓冲区的结果：

Delete on scans  (cost=0.57..1274693.83 rows=103787 width=6) (actual time=19309.026..19309.027 rows=0 loops=1)
  Buffers: shared hit=743430 read=46033
  I/O Timings: read=15917.966
  ->  Index Scan using scans_staging_scandatetime_idx on scans  (cost=0.57..1274693.83 rows=103787 width=6) (actual time=19309.025..19309.025 rows=0 loops=1)
        Index Cond: (scandatetime > (CURRENT_TIMESTAMP - '1 day'::interval))
        Filter: ((scandatetime <> (SubPlan 2)) AND (scandatetime <> (SubPlan 4)))
        Rows Removed by Filter: 74564
        Buffers: shared hit=743430 read=46033
        I/O Timings: read=15917.966
        SubPlan 2
          ->  Result  (cost=4.05..4.06 rows=1 width=8) (actual time=0.232..0.233 rows=1 loops=74564)
                Buffers: shared hit=458108 read=27849
                I/O Timings: read=15114.478
                InitPlan 1 (returns $1)
                  ->  Limit  (cost=0.70..4.05 rows=1 width=8) (actual time=0.231..0.231 rows=1 loops=74564)
                        Buffers: shared hit=458108 read=27849
                        I/O Timings: read=15114.478
                        ->  Index Only Scan using scans_staging_imb_scandatetime_idx on scans tt  (cost=0.70..20.81 rows=6 width=8) (actual time=0.230..0.230 rows=1 loops=74564)
                              Index Cond: ((imb = scans.imb) AND (scandatetime IS NOT NULL))
                              Heap Fetches: 74583
                              Buffers: shared hit=458108 read=27849
                              I/O Timings: read=15114.478
        SubPlan 4
          ->  Result  (cost=4.05..4.06 rows=1 width=8) (actual time=0.042..0.042 rows=1 loops=34497)
                Buffers: shared hit=228637 read=701
                I/O Timings: read=507.724
                InitPlan 3 (returns $3)
                  ->  Limit  (cost=0.70..4.05 rows=1 width=8) (actual time=0.041..0.041 rows=1 loops=34497)
                        Buffers: shared hit=228637 read=701
                        I/O Timings: read=507.724
                        ->  Index Only Scan Backward using scans_staging_imb_scandatetime_idx on scans tt_1  (cost=0.70..20.81 rows=6 width=8) (actual time=0.040..0.040 rows=1 loops=34497)
                              Index Cond: ((imb = scans.imb) AND (scandatetime IS NOT NULL))
                              Heap Fetches: 34497
                              Buffers: shared hit=228637 read=701
                              I/O Timings: read=507.724
Planning Time: 5.350 ms
Execution Time: 19313.242 ms

【问题讨论】：

什么是非常慢...需要很长时间才能运行？请通过实际的数字比较来限定。
这个查询将需要 30,000 秒才能运行，如果不是更多的话
@a_horse_with_no_name 更新了简单的解释，运行完成后将添加分析
您要保留的每个 imb 1. 最新的行，2. 超过 21 天的所有行，3. 如果最旧的行在过去 21 天内，那么也是。是吗？
您能否将“21 天”更改为“1 天”以便更快速地获得EXPLAIN (ANALYZE, BUFFERS)？

标签： sql postgresql

【解决方案1】：

没有预聚合（并避免 CTE）：

DELETE FROM scans del
WHERE del.scandatetime > (current_timestamp - interval '21 days')
AND EXISTS (SELECT *
        FROM scans x
        WHERE x.imb = del.imb
        AND x.scandatetime < del.scandatetime
        )
AND EXISTS (SELECT *
        FROM scans x
        WHERE x.imb = del.imb
        AND x.scandatetime > del.scandatetime
        )
        ;

这个想法是：只有在之前（至少）有一条记录，并且（至少）在它之后有一条记录时，您才删除。（使用相同的 imd）这不适用于第一条和最后一条记录，仅适用于中间的记录。

【讨论】：

你能再解释一下吗？在我看来，这似乎不会保留最大和最小时间戳。如果有 4 个扫描事件早于 del.scandatetime 会怎样，它不会按原样将它们全部删除吗？
我选择这个作为答案，因为它也适用于 Redshift。 Redshift 目前不支持删除中的 with 子句
CTE 版本也可能很慢。例如，在 Pg-12 (?) 之前的 Postgres 中。

【解决方案2】：

考虑运行聚合一次并将其合并到EXISTS 子句中。

with agg as (
   select imb
          , min(sub.scandatetime) as min_dt
          , max(sub.scandatetime) as max_dt
   from scans
   group by imb
)

delete from scans s
where s.scandatetime > (current_timestamp - interval '21 days')
  and exists
     (select 1
      from agg
      where s.imb = agg.imb
        and (s.scandatetime > agg.min_dt and
             s.scandatetime < agg.max_dt)
     );

【讨论】：

【解决方案3】：

在请求 cmets 中，您说该表不包含超过 21 天的行。因此条件scandatetime > (current_timestamp - interval '21 days') 是多余的。这也意味着您从表中删除了几乎所有行。每个 imb 只保留一到两行。

DELETE 在这么多行（您提到数千万行）上可能会非常慢。不仅要一一删除表行，还要更新所有索引。

这就是说，您最好将那几行所需的行复制到临时表中，截断原始表并将行复制回来。 TRUNCATE 不像 DELETE 那样查看单行。它只是一次性清空整个表及其索引，并立即回收磁盘空间。

脚本看起来像这样：

create table temp_desired_scans as
select *
from scans s
where (imb, scandatetime) in 
(
  select imb, min(scandatetime) from scans group by imb
  union all
  select imb, max(scandatetime) from scans group by imb
);

truncate table scans;

insert into scans
select * from temp_desired_scans;

drop table temp_desired_scans;

（这种批量删除的另一个常见选项是保留临时表，删除原始表，将临时表重命名为原始表的名称，并在这个新表上安装所有约束和索引。）

【讨论】：

我在评论中说错了，我的意思是基本上在 21 天后数据被认为是最终的。我们需要保留它，因为 IMB 代表实际的扫描事件，但 21 天后它们引用与旧扫描事件完全无关的新扫描事件。本质上，21 天窗口中的数据是动态的，而任何较旧的数据都是静态的。我们仍然需要它。
好的。您是否知道您的报表没有保留过去 21 天的第一个和最后一个条目？如果 imb 的第一个条目较旧，则保留该条目（无论如何您都会这样做），但删除过去 21 天内的所有行，最新的行除外。
如果您主要在表中的最后 21 天工作，您可能需要考虑按日期对表进行分区。

【解决方案4】：

鉴于选择是问题所在，我将只专注于选择。您可以随时从中删除。如果有帮助，你可以试试这个表格：

select * from
(select *,
    row_number() over (partition by imb order by scandatetime asc) ar,
    row_number() over (partition by imb order by scandatetime desc) dr
 from scans
)s 
where ar>1 and dr>1 and scandatetime>(current_timestamp - interval '21 days')

【讨论】：