DB2星型连接Star Join如何优化才能提升查询性能？

在数据仓库场景中，星型模型（Star Schema）是最典型的建模方式：一张巨大的事实表位于中心，多张规模较小的维度表通过外键与之关联。当一条查询同时关联四五张维度表并带有过滤条件时，如果DB2选择普通的嵌套循环连接或哈希连接，往往需要先扫描整张事实表再逐个关联，代价极高。星型连接优化的本质，是在访问事实表之前，先用维度表的过滤结果构造出精简的连接键集合，让事实表的访问从一开始就只触碰少量符合条件的数据。理解并利用好DB2的这一特性，往往是数仓查询性能提升数倍的关键。

一、星型连接的工作原理与执行流程

星型连接的核心思想可以概括为一句话：先算维度，再碰事实。在传统连接计划中，优化器可能选择先扫描事实表，再依次与维度表做哈希连接或嵌套循环连接。而星型连接计划会把所有带过滤条件的维度表先提取出来，对它们的连接键做笛卡尔积运算（此时维度表已经过WHERE条件过滤，规模很小），得到一个键值组合的集合，然后利用事实表上建立在连接列上的复合索引，直接定位满足条件的事实表行。

举个例子，销售事实表SALES有十亿行，维度表包括日期表DIM_DATE、产品表DIM_PRODUCT、地区表DIM_REGION。查询要求2013年第一季度、华东地区、某品类产品的销售明细。三张维度表过滤后分别剩下一百行、五十行、二十行，做笛卡尔积最多也就十万种组合。DB2利用事实表上（DATE_KEY, PRODUCT_KEY, REGION_KEY）的复合索引，通过多索引AND操作（索引ANDing）直接命中目标数据，完全避免扫描十亿行。这种执行计划在执行计划输出中通常表现为HSJOIN^NLJOIN的组合，以及事实表侧出现多个索引扫描通过RID AND操作合并的节点。

需要注意的是，星型连接并不总是要求维度表之间做笛卡尔积。DB2也可能采用位图方式或先与其中一张维度表连接再回事实表的方式，具体取决于优化器估算的成本。无论哪种形态，判断标准都是一致的：事实表的大范围扫描被避免或大幅缩减，代价被前置到小表的处理上。

二、触发星型连接的前提条件

星型连接不会自动出现在任何星型模型查询上，DB2优化器在生成星型连接计划前会检查一系列条件。首先是统计信息：维度表和事实表必须有准确的统计信息，特别是维度表的基数（CARD）和过滤后的估算行数（FILTER FACTOR）。如果维度表没有RUNSTATS，优化器无法判断它是小表，自然不会考虑星型计划。建议对维度表执行完整的RUNSTATS并带WITH DISTRIBUTION选项，让优化器掌握数据分布情况。

第二个关键条件是事实表上必须存在覆盖连接键的索引。复合索引的列顺序应与查询中维度表连接的顺序配合，通常把过滤性最强的维度键放在前面。单列索引也可以工作，DB2支持多个单列索引的AND运算，但复合索引在定位效率上通常更优。示例如下：

-- 在事实表上创建复合索引，列顺序按过滤强度排列
CREATE INDEX IDX_SALES_STAR ON SALES (REGION_KEY, PRODUCT_KEY, DATE_KEY)
  INCLUDE (SALE_AMT)
  COLLECT DETAILED STATISTICS;

-- 对维度表收集带分布的统计信息
RUNSTATS ON TABLE DWH.DIM_REGION
  WITH DISTRIBUTION ON COLUMNS (REGION_KEY, REGION_NAME)
  AND DETAILED INDEX ALL;

第三个条件是维度表规模与事实表规模的悬殊比例。一般经验上，维度表过滤后行数应远小于事实表行数的百分之一，优化器才倾向于选择星型连接。如果某个维度表本身就有千万行数据且过滤后仍剩百万行，笛卡尔积代价过高，DB2会放弃星型计划。此外，查询语句本身也有影响：事实表与维度表之间必须是等值连接，连接谓词必须是可下推的简单形式，复杂的表达式或函数包装的连接列会阻止星型计划的生成。

三、如何确认并干预执行计划

确认查询是否走上星型连接，最直接的方法是查看执行计划。使用EXPLAIN工具或db2expln命令，重点观察事实表访问方式这一段：

-- 生成格式化的访问计划
db2expln -d DWHDB -t -g -f query.sql -o plan.txt

-- 或者使用EXPLAIN工具配合db2exfmt
db2 set current explain mode explain
db2 "SELECT ..."
db2exfmt -d DWHDB -1 -o star_plan.txt

在db2exfmt的输出中，如果看到事实表侧出现多个IXSCAN（索引扫描）节点汇聚到同一个RID AND运算节点（通常标注为AND运算或NLJOINn），并且维度表之间出现了笛卡尔积运算（标记为笛卡尔乘积），基本可以确认星型连接计划已经生效。反之，如果看到事实表被关系扫描（TBSCAN）后再做HSJOIN，说明星型连接没有触发，需要排查原因。

当优化器估算出现偏差时，可以借助优化概要文件强制干预。优化概要文件通过XML定义，允许指定连接顺序、连接方法和访问方法。例如强制某个查询使用特定的复合索引并按维度表优先的顺序连接，可以规避估算不准导致的劣质计划。干预手段还包括调整注册变量，例如启用星型连接相关的优化行为：

-- 启用动态位图过滤相关能力（以LUW为例，具体值参考版本文档）
db2set DB2_REDUCED_OPTIMIZATION=*
db2set DB2_HASH_JOIN=YES

-- 提高优化级别，让优化器探索更多计划空间
db2 set current query optimization = 9;

优化级别对星型连接影响明显。默认级别5会在计划空间和编译时间之间折中，某些复杂星型查询在级别7或9下才能探索到星型计划，但编译时间会增加，需要根据查询频率权衡。

四、常见优化失败原因与排查思路

实践中星型连接未能生效的原因高度集中在几类。第一类是统计信息缺失或过期，事实表增量加载后没有重新RUNSTATS，优化器手中的基数数据与实际严重不符。第二类是索引不匹配，复合索引的列顺序与查询的连接列顺序不一致，或者连接列上被包裹了函数（例如TO_CHAR(DATE_KEY)），导致索引无法使用。第三类是查询写法问题，比如在维度表关联条件之外还混入了事实表与事实表的自关联，或者使用了OR连接的复杂谓词，破坏了星型模式的规整性。

排查时建议按顺序检查：先确认统计信息是否新鲜，再对照执行计划查看事实表索引是否被使用，然后检查谓词形式是否规整，最后尝试提高优化级别或使用优化概要文件验证星型计划是否带来实际收益。可以用事件监视器或监控表函数对比优化前后的实际执行时间，避免只是计划形态变了但总耗时反而增加的情况。另外，MQT（物化查询表）也是星型查询的强力补充手段，将常用的维度聚合结果预先物化，配合优化器自动路由查询到MQT，往往比单纯调整连接计划效果更稳定。

总结来说，DB2星型连接优化是一个系统工程：准确的数据统计、精心设计的复合索引、规整的查询写法以及必要时的计划干预手段，四者配合才能让数据仓库中的大表关联查询稳定跑出理想性能。

DB2星型连接Star Join优化修改时间：2026-08-31 08:10:55