Redshift UPDATE使用Seq扫描非常慢

Question

我必须在一个大表（600m行）中更新约300行，并且我试图使其更快。

我正在使用的查询有点棘手：

UPDATE my_table
SET name = CASE WHEN (event_name in ('event_1', 'event_2', 'event_3')) 
THEN 'deleted' ELSE name END
WHERE uid IN ('id_1', 'id_2')

我尝试在此查询上使用EXPLAIN，并且得到：

XN Seq Scan on my_table  (cost=0.00..103935.76 rows=4326 width=9838)
   Filter: (((uid)::text = 'id_1'::text) OR ((uid)::text = 'id_2'::text))

我有一个交错的排序键，而uid是此排序键中包含的列之一。 查询看起来像这样的原因是，在实际情况下，SET中的列数（以及名称）可能会有所不同，但可能不会超过10。基本思想是我不想交叉连接（更新规则特定于列，我不想将它们混合在一起）。 例如，将来会有类似的查询：

UPDATE my_table
SET name = CASE WHEN (event_name in ("event_1", "event_2", "event_3")) THEN 'deleted' ELSE name END,
address = CASE WHEN (event_name in ("event_1", "event_4")) THEN 'deleted' ELSE address END
WHERE uid IN ("id_1", "id_2")

无论如何，回到第一个查询，它会运行很长时间（大约45分钟），并占用100％的CPU。

我试图检查甚至更简单的查询：

explain UPDATE my_table SET name = 'deleted' WHERE uid IN ('id_1', 'id_2')
XN Seq Scan on my_table  (cost=0.00..103816.80 rows=4326 width=9821)
   Filter: (((uid)::text = 'id_1'::text) OR ((uid)::text = 'id_2'::text))

我不知道我还可以在问题中添加些什么，以使其更清楚，我们很高兴听到任何建议。

Answer 1

您是否尝试过删除交错的排序键并用uid上的简单排序键或以uid作为第一列的复合排序键替换它？

另外，名称uid使我认为您可能正在使用GUID / UUID作为值。 我建议这是Redshift中id值的反模式 ，尤其是对于排序键。

GUID / UUID id ：

• 不要以可预测的顺序发生
  • 通常触发完整的顺序扫描
  • 新行总是会破坏排序
• 压缩效果很差
  • 需要更多磁盘空间来存储
  • 查询时需要读取更多数据

Answer 2

redshift中的update是删除，然后插入。 根据设计，红移只是将行标记为已删除，而不是物理删除它们（虚拟行）。 显式真空仅删除<table_name>即可回收空间。

顺序 扫描受这些幻影行影响。 建议运行以上命令并稍后检查查询性能。