2017-09-05 85 views
0

我是RedShift的新手,只是在此阶段尝试帮助进行表格设计。AWS Redshift查询计划警告

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

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

的STL_Alert_Event_Log条目是: '非常有选择性的查询过滤器:比=行(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| 

所以应该不会有被扫描(3×262085),而不是524170(2×262085)作为上市的计划786255行?

回答

2

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

2

侧面观察:如果你总是使用两个benchmarkidUniverseID选择值,你应该使用DISTKEY EVEN

原因是benchmarkid DISTKEY会根据benchmarkid在切片之间分配数据。给定的benchmarkid的所有值将位于同一片上。如果您的查询总是在查询中提供benchmarkid,那么查询仅使用一个切片。另一方面,如果它使用DISTKEY EVEN,那么每个切片都可以参与查询,使其更有效率(对于具有WHERE benchmarkid = xxx的查询)。

一般的经验法则是:

  • 使用DISTKEY在WHERE
+0

感谢对此有何评论常用常用领域JOIN或GROUP BY

  • 使用SORTKEY的领域它可以帮助扩大我的理解。 – GKall