GKa*_*all 3 amazon-web-services amazon-redshift
我是 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
Run Code Online (Sandbox Code Playgroud)
我们的表 DDL 是:
CREATE TABLE public.LargeNumberofRowswithUniKey
(
benchmarkid INTEGER NOT NULL DISTKEY,
UniverseID INTEGER NOT NULL
)
SORTKEY
(
benchmarkid,UniverseID
);
Run Code Online (Sandbox Code Playgroud)
我们还在表上运行以下命令:
Vacuum full public.LargeNumberofRowswithUniKey;
Analyze public.LargeNumberofRowswithUniKey;
Run Code Online (Sandbox Code Playgroud)
该计划的屏幕截图如下:[查询计划图像][1] 我的期望是,包括 Benchmark 和 Universe 在内的多个排序键以及两者都是过滤谓词的一部分的事实将确保设计对于示例查询是最佳的。情况似乎并非如此,因此附图中出现了红色警告符号。谁能阐明这一点?
谢谢
乔治
更新 2017/09/07 我有一些可能有帮助的更多信息:
如果我运行一个更简单的查询,它只过滤排序键的第一列。
select r.benchmarkid
from LargeNumberofRowswithUniKey r
where r.benchmarkid = 291891
Run Code Online (Sandbox Code Playgroud)
这会导致根据控制台的实际查询计划扫描 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|
Run Code Online (Sandbox Code Playgroud)
那么,难道不应该扫描 786,255 行 (3 x 262,085),而不是计划中列出的 524,170 (2 x 262,085) 行吗?
侧面观察:如果您始终使用benchmarkid和来选择值UniverseID,那么您可能应该使用DISTKEY EVEN。
这样做的原因是 abenchmarkid DISTKEY会根据 来在切片之间分配数据benchmarkid。给定的所有值都benchmarkid将位于同一切片上。如果您的查询始终在查询中提供 a benchmarkid,则查询仅使用一个切片。
另一方面,如果使用DISTKEY EVEN,则每个切片都可以参与查询,从而使其更加高效(对于使用 的查询WHERE benchmarkid = xxx)。
一般经验法则是:
DISTKEYJOIN 或 GROUP BY 中常用的字段SORTKEYWHERE 中常用的字段| 归档时间: |
|
| 查看次数: |
3424 次 |
| 最近记录: |