Redshift 需要记住的一件事是，在 VACUUM 运行之前，删除的记录实际上只是“软”删除。
- 它们保留在表格中，标记为要忽略
- 它们仅在真空后被删除
但是，大表上的 VACUUM 中散布着删除，实际上通常比“深度复制”慢。 （将数据复制到另一个表中，使用GROUP BY或DISTINCT消除重复，TRUNCATE原表重新插入数据或删除原表并重命名新表。） em>
这是您实际上可能从感觉“缓慢”的过程中受益的一般理由。
此外，如果两行确实相同，则无法（根据定义）唯一标识一行。在这种情况下，您无法区分要保留的和要删除的。
其他 RDBMS 中的一个“技巧”是在公用表表达式中使用 ROW_NUMBER()，然后从该 CTE 中删除。 （通过 CTE 创建唯一标识符，允许您识别要保留或删除的各个行。）不幸的是，Redshift 目前不支持从 CTE 中删除。
在此更改之前，深度复制 （在使用GROUP BY 或DISTINCT 时复制到单独的表） 目前是您唯一的选择。
即便如此，深拷贝选项在 Redshift 中可能仍然更有效，即使从 CTE 中删除确实成为可能。
编辑：
更正：
如果 Redshift 表中的任何行已被删除，任何后续的 VACUUM 都会重新处理 整个表 （无论删除的行在哪里，或者如何有很多已删除的行）。
（在 INSERT 之后进行 VACUUMing 会更复杂，但在 DELETE 之后会非常丑陋。）
我还注意到 深拷贝 比 VACUUM 使用更少的磁盘空间。 （只有在磁盘空间用完时才引起我的注意...）
编辑：
代码示例：
CREATE TABLE blah_temp (
<Exactly the same DDL as the original table, especially Distribution and Sort keys>
)
;
INSERT INTO
blah_temp
SELECT DISTINCT
*
FROM
blah
;
DROP TABLE blah;
ALTER TABLE blah_temp RENAME TO blah;
或者……
CREATE TABLE blah_temp (
<Exactly the same DDL as the original table, especially Distribution and Sort keys>
)
;
INSERT INTO
blah_temp
SELECT
*
FROM
blah
GROUP BY
a, b, c, d, e, f, g, etc
;
TRUNCATE TABLE blah;
INSERT INTO
blah
SELECT
*
FROM
blah_temp
;
DROP TABLE blah_temp;
相关链接：https://docs.aws.amazon.com/redshift/latest/dg/performing-a-deep-copy.html