一条范围查询的执行计划是否合理，关键看优化器能否准确估算过滤后的行数。当一张表的统计信息足够完整时，传统直方图能够给出比较准确的全局估算；但如果查询访问的是某个很小的键区间，或者数据存在明显的局部聚集，全局统计就可能与局部真实分布产生较大偏差。DB2 提供的 opt_enable_partial_forecast 参数正是为了解决这类场景下的基数估算问题。该参数控制优化器是否启用部分预测，允许在谓词区间上使用更细粒度的局部统计信息，而不是只依赖全表级的频率分布或分位数。

启用这个参数之后，优化器在面对范围谓词、等于谓词或 IN 列表时，会尝试从已经收集的统计信息中识别可用的局部特征，并对过滤因子进行二次修正。对于时间序列表、按日期分区的表以及持续增长的日志表，这种修正通常能提高执行计划选择的稳定性，避免因为估算行数过低而误选全表扫描，或者因为估算过高而放弃合适的索引。

一、opt_enable_partial_forecast 的作用边界

部分预测并不是替代原有的基数估计模型，而是在原有模型之上增加一层局部修正。传统优化器在估算 range 谓词时，会从直方图的桶边界中插值，得到一个平均的选择率。这种方式在数据分布均匀时效果尚可，但在分布偏斜时误差会被放大。例如一张按地区编码存储的表，某几个地区占 80% 的数据，如果查询只落在其中一个稀疏地区，全局直方图可能给出过低的过滤因子，导致优化器高估回表成本。

启用部分预测后，优化器会优先分析谓词涉及的局部区间。如果该区间对应着较为明确的边界或者有统计视图提供局部采样，优化器就利用这些信息重新计算行数估计。这里的关键词是“部分”：优化器不要求获得完整的表扫描结果，也不要求覆盖所有列，只要局部信息足够可靠，就可以参与估算。这也是参数名称中出现 partial 的原因。

该参数的适用场景比较集中。包括按时间字段进行范围查询的流水表、数据持续追加导致统计信息滞后的表、以及存在多列相关但统计信息只收集了单列的情况。对于这些场景，开启部分预测通常能够改善谓词过滤因子的准确性。但如果表很小或者查询总是返回全表大部分数据，开启该参数可能不会带来明显收益，反而会增加优化阶段的判断成本。

二、启用前检查与配置方法

在 DB2 中，opt_enable_partial_forecast 通常通过注册变量或数据库配置参数控制，具体取决于部署版本和实例配置。启用之前建议先检查当前设置，确认该开关是否已经存在以及目前的值。管理员可以在数据库服务器上执行以下命令：

db2set -all | grep -i partial_forecast

如果命令没有返回任何内容，说明该注册变量尚未显式设置。此时可以通过 db2set 命令写入值：

db2set DB2_OPT_ENABLE_PARTIAL_FORECAST=ON
db2stop force
db2start

这里的 DB2_OPT_ENABLE_PARTIAL_FORECAST 是注册变量名称，值设置为 ON 表示启用。对于使用数据库配置参数的环境，则可以在连接数据库后执行：

UPDATE DB CFG USING opt_enable_partial_forecast ON IMMEDIATE

上述语句中的参数名和可用值应以目标版本的官方文档为准。配置完成后，并不代表所有 SQL 立即使用新的预测模型。优化器在编译语句时决定是否采用部分预测，因此对于已经缓存在包缓存中的执行计划，需要重新绑定相关包，或者等待计划自然老化。更稳妥的做法是对关键 SQL 执行一次 REBIND，强制重新生成访问计划。

如果是生产环境首次启用，建议先在测试库上打开该参数，使用与生产相同的统计信息和典型查询负载进行对比。观察参数开启前后访问计划是否发生变化，尤其是过滤因子和预估行数是否更符合实际返回值。对于变化较大的 SQL，可以进一步收集更细致的统计信息，例如执行 RUNSTATS ON TABLE ... WITH DISTRIBUTION AND DETAILED INDEXES ALL，为部分预测提供更可靠的输入。

三、执行计划对比与注意事项

验证参数效果最直接的方式是对同一查询在开关前后生成执行计划。可以使用 EXPLAIN PLAN FOR 写入计划表，再通过 db2exfmt 查看估算基数。也可以使用更轻量的 db2batch 观察实际执行时间与读取页数。通常重点关注范围谓词的过滤因子，如果开启后过滤因子从几十倍偏差降到接近实际选择率，说明部分预测在该查询上起到了作用。

EXPLAIN PLAN FOR
SELECT * FROM orders
WHERE order_date BETWEEN CURRENT DATE - 7 DAYS AND CURRENT DATE

执行计划中会显示每个操作符的预估行数和累计成本。需要注意，部分预测不一定会改变执行计划的拓扑结构，它可能只调整某些操作符的基数估算和代价权重，从而让优化器在索引扫描和表扫描之间做出不同选择。因此不能只盯着是否换了访问路径，还要看行数估计是否更接近实际。

启用该参数也会带来一些额外开销。优化器在编译阶段需要判断局部统计信息是否可用，并对候选计划进行评估，这会增加一定比例的优化时间。对于以极短查询为主、每秒并发编译量很大的 OLTP 系统，如果每条 SQL 的编译时间被拉长，可能对整体吞吐造成轻微影响。因此建议在启用后观察数据库的包缓存命中率、平均编译时间和 CPU 使用率，而不是盲目长期开启。

另外，部分预测的效果强依赖统计信息的质量。如果表从未执行过 RUNSTATS，或者统计信息长时间未更新，局部预测没有可靠的输入，自然不会产生明显改善。启用该参数的同时，应配套更新高变化表的统计信息收集策略。对于按日期快速增长的日志表，可以考虑缩短统计信息更新周期，或者使用实时统计信息特性让优化器在编译时获取更准确的元数据。

最后，如果在某些 SQL 上发现开启后执行计划反而变差，可以用优化器概要或 OPTGUIDELINES 等方式针对单个语句关闭该特性，而不必全局回退。这样既保留了大部分查询的收益，又能控制个别异常计划的波动。