DB2优化器参数opt_enable_partial_data_quality_improvement如何启用部分数据质量改进？

在DB2数据库的性能调优过程中，优化器生成的执行计划质量直接决定了SQL语句的响应速度。而执行计划的好坏，很大程度上取决于优化器对表和列统计信息的利用程度。有一个名为opt_enable_partial_data_quality_improvement的注册表变量或数据库配置参数（不同版本叫法略有差异），专门控制优化器是否对部分数据质量问题进行改进。简单来说，当这个参数被启用时，优化器可以在某些条件下放弃对全部列做完整的数据质量分析，而是采用部分改进策略，以便更快地完成计划生成。这个参数默认是关闭的，因为启用它虽然能降低优化阶段的CPU开销，却可能让优化器基于不完整的质量信息做出基数估算，从而影响到最终的执行计划选择。

要理解这个参数的实际价值，需要先搞清楚优化器中的“数据质量”指什么。在DB2里，当一张表或一个索引的统计信息过期或者缺失时，优化器会尝试通过实时采样来修复部分统计信息。这种修复过程被称为数据质量改进（Data Quality Improvement）。完整的数据质量改进可能涉及对多个列的分布统计、频繁值统计、直方图等做全面的重新收集，代价很高。而“部分数据质量改进”则是一种折中：只对那些优化器认为最关键、对基数估算影响最大的列进行修复，跳过其余列。这样一来，优化阶段的时间可以从几分钟缩短到几秒，尤其适合数据仓库环境中包含大量大表的复杂连接查询。

参数如何启用与生效范围

启用这个参数的方法取决于DB2的部署方式。在Linux/Unix/Windows平台的DB2中，它通常是一个DB2注册表变量，可以通过db2set命令设置。例如：

db2set DB2_OPTPARTIALDQ=YES
db2stop
db2start

有些较新的DB2版本也把它作为数据库配置参数，可以通过UPDATE DB CFG来修改。设置完成后，需要重新激活数据库或重启实例才能让优化器识别新值。需要注意的是，这个参数是全局性的，一旦启用，所有后续的SQL语句在优化阶段都会受到影响。因此，生产环境直接全局开启存在一定风险，更常见的做法是在会话级别通过SET CURRENT QUERY OPTIMIZATION之类的机制动态控制，或者先在测试库上评估效果。

从作用范围来看，这个参数只影响优化器生成执行计划时的数据质量改进行为，不会影响运行时数据的实际校验。例如，表上的NOT NULL约束、检查约束、外键约束仍然会正常执行，不会因为优化器跳过了部分质量检查而失效。此外，它也不会改变查询返回的结果集，只会让优化器基于不那么精确的统计估算来挑选连接顺序和访问路径。如果优化器恰好做出了错误的选择，查询性能反而可能下降，这正是需要谨慎对待的原因。

开启前后的执行计划对比

为了直观展示这个参数的影响，我们构造一个包含三张表连接的场景。三张表分别有数百万行数据，其中一张表的某个列存在严重的数据倾斜，但该列上的统计信息已经过期。在参数关闭的情况下，优化器会对这三张表的多数列执行完整的数据质量改进，生成计划耗时可能达到数十秒。而开启参数后，优化器只对连接谓词涉及的关键列做质量修复，其余列直接使用过期的统计信息，计划生成时间可以降低到几秒以内。

下面是关闭参数时优化器生成的访问计划摘要，注意其中对表T2的基数估算：

Access Plan:
-----------
Total Cost:             12345.67
Query Degree:           1

Rows
              RETURN
              (   1)
               |
               ...
              ( 25000)
               |
             TBSCAN
             ( 98765)
             Table:
             USER1.T2
             Estimated Cardinality: 98765
             Actual Cardinality: 152000

开启参数后，优化器可能不再对T2的非连接列做直方图重建，此时估算基数可能更偏离实际：

Access Plan:
-----------
Total Cost:             9876.54
Query Degree:           1

Rows
              RETURN
              (   1)
               |
               ...
              ( 12000)
               |
             TBSCAN
             ( 78000)
             Table:
             USER1.T2
             Estimated Cardinality: 78000
             Actual Cardinality: 152000

对比可以看出，开启参数后优化器对T2的估算从98765变成了78000，与实际基数的偏差从35%扩大到接近49%。虽然计划生成时间变短了，但如果这个估算误差导致优化器错误地选择了嵌套循环连接而不是哈希连接，整体查询时间可能会急剧增加。因此，这个参数并不是无条件推荐的，它更适合那些优化时间远大于执行时间的场景，比如包含数十个表连接的即席查询，或者统计信息频繁变动导致优化器反复做全量修复的环境。

监控与回退策略

如果你决定在某个环境启用这个参数，建议配套一套监控机制。可以通过数据库的EXPLAIN输出观察优化计划中关键表的基数估算是否发生显著漂移，同时监控MON_GET_PKG_CACHE_STMT表函数中优化时间相关的指标。此外，DB2的优化器事件监视器可以记录数据质量改进发生的次数和花费的时间，利用这些信息可以判断参数是否真正减少了优化阶段的负担。

一旦发现启用后某些核心SQL的执行时间明显变长，可以立即将参数关闭并重新收集相关表的统计信息。回退操作非常简单，对于注册表变量，执行db2set DB2_OPTPARTIALDQ=NO然后重启实例即可。对于数据库配置参数，则使用UPDATE DB CFG USING opt_enable_partial_data_quality_improvement OFF。回退后优化器将恢复完整的质量改进行为，虽然优化时间会增加，但执行计划的质量更有保障。另外，即便不关闭参数，也可以通过手动对关键表执行RUNSTATS并加上WITH DISTRIBUTION选项，提前把高质量统计信息准备好，从而降低优化器运行时做质量改进的必要性，这往往比依赖参数更可控。

总体而言，opt_enable_partial_data_quality_improvement是一个典型的“以精度换时间”的优化器调优开关。它并不适合所有场景，但在大型数据仓库的复杂即席查询负载下，能够有效缓解优化阶段的资源消耗。理解它的工作机制、监控其影响并准备好快速回退，才能让这个参数真正成为你的调优工具，而不是埋下性能隐患。

DB2opt_enable_partial_data_quality_improvement数据质量改进修改时间：2026-09-29 00:40:47