Redshift高基数列排序键与连接键选择的最佳实践咨询

问题1：维度表PART_NUMBER单值查询是否会触发全表扫描？ #

不会触发全表扫描，但效率取决于排序键顺序与数据分布：

• Redshift的排序键遵循前缀匹配逻辑，如果维度表排序键设为(PK, PART_NUMBER)，查询WHERE PART_NUMBER = 'XXX'时，虽无法直接利用排序键的前缀有序性快速定位，但会通过Zone Maps跳过不包含目标值的数据块，避免全表扫描。
• 若PART_NUMBER查询频率远高于与事实表的关联操作，可将维度表排序键调整为(PART_NUMBER, PK)——但这会影响和事实表的merge join效率，需根据业务优先级权衡：
  • 关联操作占比更高：保留(PK, PART_NUMBER)排序键，依赖Zone Maps优化单值查询；
  • PART_NUMBER查询占比更高：优先将其设为主排序键，关联时若性能不足，可考虑基于PK创建物化视图用于关联。

问题2：事实表多FK设为复合键，关联时能否用merge join？ #

可以，但需满足两个核心前提：

• 关联的维度表PK必须是自身排序键的前缀，同时事实表对应的FK是事实表排序键的前缀；
• 关联列在事实表与维度表中排序顺序一致，且两者的分布键（Dist Key）匹配（通常事实表Dist Key设为高频关联的维度PK，避免数据重分布）。
• 例：事实表复合排序键为(date_key, product_key, part_key)，product维度表排序键为(product_key)，则两者关联时可触发merge join；但如果关联part_key（非事实表排序键前缀），则大概率走哈希或嵌套循环join。

与Oracle Bitmap索引的差异说明 #

Redshift无类似Oracle的bitmap索引，优化逻辑完全基于排序键、分布键与Zone Maps：

• Oracle多列bitmap索引不依赖谓词顺序，但Redshift排序键仅支持前缀匹配，谓词列需是排序键前缀才能最大化效率；
• 对于高基数列（如PART_NUMBER），Redshift无需创建索引，依赖排序键有序性与Zone Maps快速过滤，逻辑类似Oracle的B-tree索引，但实现方式不同。

内容的提问来源于stack exchange，提问作者Pato