Redshift查询性能优化及CPU利用率降低方案咨询

一、通用优化遵循的系统性逻辑 #

• 优化优先级按「查询写法调整→表结构优化→集群资源调优」从高到低执行，避免盲目修改底层表结构浪费成本
• 多表关联场景优先统一关联键的分布规则，再优化过滤字段的排序规则，最后调整查询逻辑减少跨节点数据shuffle，核心目标是尽量让关联操作在单节点内完成，减少数据传输开销

二、优化需重点关注的表指标及对应思路 #

分布类指标 #

• 核心看系统表svv_table_info中的diststyle（分布类型）、skew_rows（数据倾斜率）两个指标
  • 若单分片数据量超过平均分片的1.1倍（倾斜率>10%），必须调整分布键为高频关联键，避免关联时个别节点负载过高拖慢整体查询
  • 小于100万行的小维度表直接设置为ALL分布，避免关联时跨节点广播小表数据
• 查询分布倾斜的参考命令：

select "schema", "table", diststyle, skew_rows from svv_table_info where "schema" = '你的业务schema名称';

排序类指标 #

• 核心看系统表svv_diskusage中的unsorted（未排序数据占比）、sortkey1_entropy（首排序键区分度）两个指标
  • 未排序占比超过20%时排序键完全失效，会导致全表扫描，需要重新做排序整理
  • 首排序键优先选高频where过滤字段，其次是join关联字段，不要用低基数字段（比如只有几个枚举值的状态字段）当首排序键，区分度太低无法起到裁剪效果

存储类指标 #

• 核心看encoded（字段压缩状态）、扫描行数/表总行数的比值两个指标
  • 有未压缩字段的表必须开启自动编码，大字段压缩后能减少30%以上的IO扫描开销
  • 若单查询扫描行数远大于最终结果行数，说明过滤裁剪失效，优先调整排序键适配常用过滤条件

三、可落地的优化执行计划步骤 #

1. 基线采集阶段
   • 拉取慢查询日志，提取top10耗时最高的多表关联查询，导出每个查询的执行计划，记录扫描行数、shuffle数据量、节点等待时间三个核心指标
   • 扫描所有关联查询涉及的业务表，汇总分布倾斜、未排序占比、压缩状态等数据，形成现状台账
2. 查询写法优化阶段
   • 去掉所有select *写法，只提取查询需要的字段
   • 关联前先在子查询中过滤数据，减少参与关联的数据集大小
   • 禁用不等值关联、笛卡尔积关联，小表统一放在join语句的右侧
3. 表结构优化阶段
   • 所有参与关联的大表，分布键统一设置为高频关联键，关联键字段类型必须完全一致，避免隐式转换导致分布规则失效
   • 按「过滤字段>关联字段>分组字段」的优先级设置复合排序键
   • 执行VACUUM SORT ONLY清理未排序数据，执行ANALYZE更新表统计信息，保证查询优化器生成正确的执行计划
4. 效果验证阶段
   • 重新执行优化后的查询，对比优化前后的耗时、CPU/内存占用、shuffle数据量，优化效果未达预期则回退调整分布键/排序键设置
5. 常态化运维阶段
   • 每周巡检未排序数据占比、数据倾斜情况，每月重新评估分布键、排序键的合理性，匹配业务查询逻辑的变更

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