【问题标题】:AWS Redshift Query Plan WarningAWS Redshift 查询计划警告
【发布时间】:2017-09-05 13:59:20
【问题描述】:

我是 RedShift 的新手,现阶段只是在尝试帮助进行表格设计。

我们有一个非常简单的表,大约有 600 万行和 2 个整数字段。

两个整数字段都在排序键中,但计划有一个警告 - “非常有选择性的查询过滤器”。

STL_Alert_Event_Log 条目是: '非常有选择性的查询过滤器:ratio=rows(61)/rows_pre_user_filter(524170)=0.000116'

我们正在运行的查询是:

select count(*) 
from LargeNumberofRowswithUniKey r 
where r.benchmarkid = 291891 and universeid = 300901

我们的表 DDL 是:

CREATE TABLE public.LargeNumberofRowswithUniKey
(
    benchmarkid INTEGER NOT NULL DISTKEY,
    UniverseID INTEGER NOT NULL
)
SORTKEY
(
    benchmarkid,UniverseID
);

我们还在桌子上运行了以下命令:

Vacuum full public.LargeNumberofRowswithUniKey;
Analyze public.LargeNumberofRowswithUniKey;

计划截图在这里:[查询计划图片][1] 我的期望是,包括 Benchmark 和 Universe 在内的多重排序键以及两者都是过滤谓词的一部分这一事实将确保设计对于示例查询是最优的。情况似乎并非如此,因此所附图像中的红色警告符号。有人能解释一下吗?

谢谢

乔治

2017 年 9 月 7 日更新 我有更多信息可能会有所帮助:

如果我运行一个更简单的查询,它只过滤排序键的第一列。

select r.benchmarkid 
from LargeNumberofRowswithUniKey r 
where r.benchmarkid = 291891

这会导致根据来自控制台的实际查询计划扫描 524,170 行。当我使用 STV_BLOCKLIST 查看块时。满足我的查询可能需要的相关块是:

|slice|col|tbl   |blocknum|num_values|minvalue|maxvalue|
|    1|  0|346457|       4|    262085|  291881|  383881|
|    3|  0|346457|       4|    262085|  291883|  344174|
|    0|  0|346457|       5|    262085|  291891|  344122|

那么不应该扫描 786,255 行 (3 x 262,085) 而不是计划中列出的 524,170 (2 x 262,085) 行吗?

【问题讨论】:

    标签: amazon-web-services amazon-redshift


    【解决方案1】:

    the rows selected vs rows scanned ratio is less than 0.05 时返回“非常有选择性的过滤器”警告,即与实际返回的行数相比,扫描的行数相对较多。这可能是由于表中有大量未排序的行,这可以通过运行 Vacuum 来解决。但是,正如您已经这样做了,我认为这正在发生,因为您的查询实际上是非常有选择性的(您正在选择 benchmarkid 和 Universeid 的单个组合),因此您可能会忽略此警告。

    【讨论】:

      【解决方案2】:

      侧面观察:如果您总是同时使用benchmarkidUniverseID 来选择值,您可能应该使用DISTKEY EVEN

      这样做的原因是benchmarkid DISTKEY 将根据benchmarkid 在切片之间分配数据。给定benchmarkid 的所有值将位于同一切片上。如果您的查询始终在查询中提供benchmarkid,则该查询仅使用一个切片。

      另一方面,如果它使用DISTKEY EVEN,那么每个切片都可以参与查询,从而提高效率(对于使用WHERE benchmarkid = xxx 的查询)。

      一般的经验法则是:

      • 对 JOIN 或 GROUP BY 中常用的字段使用 DISTKEY
      • 对 WHERE 中常用的字段使用 SORTKEY

      【讨论】:

      • 感谢您的评论,这有助于拓宽我的理解。
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2019-06-02
      • 1970-01-01
      • 1970-01-01
      • 2022-09-30
      • 1970-01-01
      • 2019-02-17
      相关资源
      最近更新 更多