在 Redshift 中创建大的 VARCHAR 值是否有缺点？答案

【问题标题】：Are there downsides for creating a large VARCHAR value in Redshift?在 Redshift 中创建大的 VARCHAR 值是否有缺点？
【发布时间】：2015-07-26 18:28:17
【问题描述】：

源数据不断为长度越来越大的字段抛出值。现在我正在使用 VARCHAR(200) 但我可能会选择VARCHAR(400)。使用大数有什么缺点吗？

【问题讨论】：

标签： sql ddl amazon-redshift

【解决方案1】：

“不利因素”是什么意思？如果你没有使列足够大，就会有一个非常大的缺点——你不能用它来存储你想要存储在那里的值。

至于额外的开销，您无需担心。 varchar() 类型基本上只占用值所需的存储空间，加上长度的小开销。此外，“400”并不是一个很大的数字，尤其是与“200”相比。

因此，如果您需要 400 个字节来存储值，请更改表来存储它。更改值的长度可能会产生开销。我不确定 RedShift 是否会因为类型更改而感到需要复制数据。但是，对性能的影响应该可以忽略不计。

【讨论】：

我只是假设并认为为字段分配不同数量的空间会产生额外的开销

【解决方案2】：

为了方便起见，不要养成使用最大列大小的习惯。

例如，请考虑您可能存储在 VARCHAR 列中的最大值，并相应地调整列的大小。由于 Amazon Redshift 非常有效地压缩列数据，因此创建比所需大得多的列对数据表大小的影响最小。但是，在处理复杂查询期间，可能需要将中间查询结果存储在临时表中。由于临时表没有被压缩，不必要的大列会消耗过多的内存和临时磁盘空间，这会影响查询性能。

http://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-smallest-column-size.html

【讨论】：

。 .该文档没有意义。 VARCHAR() 仅将空间用于存储的值，外加固定的少量开销 (docs.aws.amazon.com/redshift/latest/dg/r_Character_types.html)。无论该值是否未压缩，RedShift 都不应该将 varchar 值填充为长于其实际长度。
这些文档是由数据库维护人员编写的，所以我猜它的存在是有原因的。更重要的是，我已经对其进行了测试，它确实有所作为。如果我不得不猜测，我怀疑在查询处理期间，当列“重新实现”为行时，数据库会为可能巨大的列分配额外的 RAM。
Redshift 压缩列数据，因此过大的 VARCHAR 列不应影响表大小。但是，不必要的大 VARCHAR 列会影响查询性能：docs.aws.amazon.com/redshift/latest/dg/…