我有一个包含3个节点的Redshift集群。随着用户对它运行查询，我们在这种令人不快的情况下结束，其中一些查询的运行时间超过预期（即使是简单的查询，超过15分钟），并且群集存储开始增加，如果你不喜欢和＃39; t终止长期存在的查询，使其达到100％的存储空间。
我想知道为什么会这样。我的经验是多种多样的，有时它只是一个查询，有时候同时运行不同的并发查询。
答案 0 :(得分：3)
我们看到发生这种情况的一种特定情况与LISTAGG有关。 LISTAGG的类型为varchar(65535)，虽然Redshift在存储到磁盘时会优化隐式尾随空白，但是在处理过程中内存中需要全宽。
如果查询返回一百万行，则最终将得到1,000,000行乘以每个LISTAGG 65,535字节，即65 GB。这样一来，您很快就会陷入您所描述的情况，查询时间过长或出现“磁盘已满”错误而失败。
前几天，我们的团队on our team blog对此进行了更多讨论。
答案 1 :(得分：1)
这通常发生在构造不良的查询将过多数据泄露到磁盘上时。例如，用户意外地指定了笛卡尔积（tblA的每一行都连接到tblB的每一行）。
如果这种情况经常发生，您可以实施QMR规则，在查询中止之前限制磁盘溢出量。