DB2 opt_join_stats如何优化连接统计提升查询性能？

数据库优化器的所有决策都建立在对数据量的估算之上，估算越准，执行计划越合理。DB2在单表场景下的统计信息已经相当完善，但当查询涉及多表连接时，仅靠单表统计往往难以准确推断连接后的结果集规模，这时就需要启用连接统计功能，也就是常说的opt_join_stats相关能力，包括列组统计（Column Group Statistics）和统计视图（Statistical Views）。本文将围绕连接统计失真的原因、收集方法以及实际优化效果展开详细说明。

一、为什么单表统计在连接场景下会失真

DB2优化器默认依赖SYSCAT.TABLES和SYSCAT.COLUMNS中的基础统计信息，例如表的行数CARD、列的频次分布FREQUENCYVALUES以及分位数信息QUANTILES。这些统计描述的都是单个表、单个列的数据分布。当SQL中出现类似T1.CUST_ID = T2.CUST_ID这样的连接谓词时，优化器需要估算满足条件的行数，而这个估算质量直接决定连接顺序和连接方式的选择。

问题在于，两个表的连接列分布之间可能存在复杂的相关性。假设订单表中的客户ID分布高度倾斜，而客户表本身的记录分布又是另一种形态，优化器按照默认的独立性假设计算，很容易把基数估算放大或缩小数十倍。举个典型例子：订单表一千万行，客户表十万行，某些大客户在订单表中占比百分之三十，如果优化器按照均匀分布假设估算，连接中间结果可能被估成远小于实际值，从而错误地选择嵌套循环连接，导致大量随机I/O，性能急剧下降。

此外，多列之间的统计相关性也会造成估算偏差。比如查询同时过滤城市和产品类别两个条件，这两列往往高度相关（某些城市偏好某些产品），单列统计无法捕捉这种相关性，连接估算自然偏离实际。这些偏差在复杂报表SQL中会被逐层放大，最终生成的执行计划可能完全不是最优解。

二、收集连接统计：列组统计与统计视图

DB2解决连接估算失真的核心手段有两类。第一类是列组统计，通过RUNSTATS命令对多个列的组合收集联合频次分布，让优化器了解列与列之间的相关性。

-- 对表 orders 的 cust_id 和 order_date 两列收集列组统计
RUNSTATS ON TABLE db2admin.orders
  ON COLUMNS ((cust_id, order_date) WITH DISTRIBUTION);

-- 查看是否已收集列组统计
SELECT colname, colgroup
FROM SYSCAT.COLDIST
WHERE tabname = 'ORDERS';

上面的命令会对指定列组合收集分布信息，结果存放在SYSCAT.COLDIST系统表中，当colgroup字段为Y时表示该行属于列组统计。优化器在处理包含这些列的等值或范围谓词以及连接谓词时，会优先使用联合分布来修正基数估算。

第二类手段是统计视图，也叫物化统计视图。它通过定义一条代表典型连接关系的视图，并对其收集统计信息，让优化器获得连接结果的规模特征。

-- 定义统计视图描述订单与客户的连接
CREATE VIEW db2admin.v_ord_cust
AS SELECT o.order_id, o.cust_id, c.city, c.region
FROM db2admin.orders o, db2admin.customers c
WHERE o.cust_id = c.cust_id;

-- 将视图标记为统计视图
ALTER VIEW db2admin.v_ord_cust ENABLE QUERY OPTIMIZATION;

-- 对统计视图收集统计信息
CALL SYSPROC.ADMIN_CMD(
  'RUNSTATS ON VIEW db2admin.v_ord_cust WITH DISTRIBUTION');

统计视图并不会真正存储数据，它只向优化器提供统计信息。当查询中的连接结构与统计视图定义匹配时，优化器可以借助这些统计更准确地估算中间结果。需要注意的是，统计视图的匹配有一定条件，连接谓词和过滤条件需要与视图定义保持一致，否则优化器无法使用。

关于opt_join_stats相关注册变量，部分DB2版本中可以通过db2set设置参数来控制统计收集行为，具体可用的注册变量与版本有关，建议先通过db2set -all查看当前设置，再结合官方文档确认开启方式。核心思路不变：让优化器获得连接层面的分布信息，而不是只依赖单表单列统计。

三、验证优化效果：从执行计划看估算偏差修正

收集连接统计后，最重要的一步是验证效果。推荐使用db2expln或EXPLAIN工具对比收集前后的执行计划。重点关注估算基数（Estimated Cardinality）与实际返回行数的差距。

-- 设置解释模式并分析SQL
SET CURRENT EXPLAIN MODE EXPLAIN;
SELECT c.region, SUM(o.amount)
FROM db2admin.orders o, db2admin.customers c
WHERE o.cust_id = c.cust_id
  AND c.region = 'EAST'
GROUP BY c.region;
SET CURRENT EXPLAIN MODE NO;

-- 查看估算的基数
SELECT o.operator_id, o.total_cost, o.cardinality
FROM EXPLAIN_OPERATOR o
ORDER BY o.operator_id;

在没有连接统计时，可以观察到HSJOIN或NLJOIN节点的估算基数与实际行数相差一个数量级以上；收集列组统计或创建统计视图之后，估算值通常会明显贴近实际值，执行计划也随之从低效的嵌套循环切换为哈希连接或归并连接，查询耗时显著下降。

验证时还可以使用事件监控器捕获实际执行统计，与估算值做交叉比对。建议在调整统计前后各执行一次完整的语句基准测试，排除缓存和数据变化的干扰，确保性能提升确实来自统计信息的改进而非其他因素。

四、收集策略与运维建议

连接统计虽然强大，但收集成本也更高，尤其是列组统计和统计视图的分布收集会消耗额外的CPU与时间。制定策略时可以参考以下几点：第一，只对出现在慢查询连接谓词中的关键列组合收集统计，避免盲目全量收集；第二，优先使用自动统计收集（AUTO_RUNSTATS）配合自定义收集方案，让高频更新的表定期刷新连接统计；第三，对于连接关系相对固定的核心报表SQL，统计视图是性价比很高的选择，一次定义长期受益。

日常运维中还应注意统计信息的时效性。数据大幅变化后，旧的连接分布可能不再准确，必要时可通过SYSPROC.ADMIN_CMD调用异步收集，减少对在线业务的影响。同时建立执行计划回归机制，定期抓取关键SQL的估算基数，一旦发现偏差重新扩大，就触发统计刷新，形成闭环管理。

总结来说，DB2连接统计的本质是让优化器突破独立性假设的局限，用真实的数据相关性信息指导计划生成。掌握列组统计与统计视图的使用方法，配合严谨的验证流程，就能在复杂多表查询场景下获得稳定且可预期的性能表现。

DB2opt_join_stats连接统计修改时间：2026-09-02 01:48:47