在
连接列上编码会破坏查询性能吗？我让"COPY 命令"来决定编码类型。
在 gernal no 中 - 因为DIST KEY上的编码甚至会由于减少磁盘 I/O 而产生积极影响。
根据 AWS 表设计行动手册，确实存在一些边缘情况，DIST KEY上的编码会破坏查询性能：
- 查询模式将范围受限扫描应用于以下列：压缩得很好。
- 压缩良好的列的每个块都包含每个块的大量值，通常比查询感兴趣的实际值计数多得多的值。
- 查询模式所需的其他列很大或压缩不好。这些柱子>孔大小的10倍压缩列。
如果要为表找到最佳编码，可以使用 Redshift 列编码实用程序。
Amazon Redshift 是一个面向列的数据库，这意味着不是按行组织磁盘上的数据，而是按列存储数据，并在运行时从列存储中提取行。此体系结构特别适用于对具有大量列的表的分析查询，其中大多数查询仅访问所有可能的维度和度量的子集。Amazon Redshift 只能访问磁盘上与 SELECT 或 WHERE 子句中包含的列相关的那些块，并且不必读取所有表数据来评估查询。按列存储的数据也应该被编码，这意味着它被大量压缩以提供高读取性能。这进一步意味着 Amazon Redshift 不需要创建和维护索引：每一列几乎就像它自己的索引一样，存储的数据结构恰到好处。
运行没有列编码的 Amazon Redshift 集群不被视为最佳实践，当客户确保以最佳方式应用列编码时，他们会发现性能会大幅提升。
因此，您的问题不会破坏查询性能，但不是最佳实践。
AWS 受访者对此有一些详细信息：AWS Redshift ： DISTKEY/SORTKEY 列应该压缩吗？
一般：
DISTKEY can be compressed but the first SORTKEY column should be uncompressed (ENCODE raw).
If you have multiple sort keys (compound) the other sort key columns can be compressed.
Also, generally recommend using a commonly filtered date/timestamp column,
(if one exists) as the first sort key column in a compound sort key.
Finally, if you are joining between very large tables try using the same dist
and sort keys on both tables so Redshift can use a faster merge join.
基于此，我认为只要连接的两侧具有相同的压缩，我认为红移就会安全地连接压缩值。