DB2的查询优化器在生成访问计划时，依赖统计信息和内部模型对数据分布进行估计。当统计信息不够完整或者数据特征复杂时，优化器的基数估计可能出现偏差，导致选择了不理想的执行计划。为了缓解这个问题，DB2引入了一些优化器相关的注册变量和参数，其中opt_enable_partial_data_modeling就是与部分数据建模相关的一个配置项。理解它的作用机制、掌握正确的启用方式，对提升复杂查询的稳定性有实际意义。
什么是部分数据建模以及它解决了什么问题
传统的基数估计方式主要依赖RUNSTATS收集的统计信息，比如表行数、列的最小最大值、频率统计值（Frequency Values）和分位数统计值（Quantiles）。当查询谓词涉及多列组合、范围条件或者存在数据倾斜时，仅靠这些概要信息，优化器很难准确估计满足条件的行数。部分数据建模的思路是：在优化器编译查询的阶段，允许它针对查询中涉及的部分数据构建更细粒度的模型，用采样或者已有的统计扩展信息来修正基数估计，而不是完全依赖全局统计。
举个例子，假设有一张订单表，其中status列和create_time列存在明显相关性——已完成的订单大多集中在较早的时间段。如果优化器把两个谓词当作独立条件简单相乘，估计出的行数会严重偏离实际值。启用部分数据建模后，优化器可以利用列组统计信息（Column Group Statistics）或采样数据对这种相关性进行建模，从而更接近真实分布。这一点在数据仓库类型的复杂查询中尤其有价值，因为那类查询的谓词组合往往非常复杂。
需要注意的是，这个能力并不是免费的。构建模型需要在查询编译阶段消耗额外的CPU和内存，如果系统中有大量短小的查询并发执行，开启后可能反而增加编译开销。因此DB2官方默认并不一定开启此类能力，而是留给数据库管理员根据负载特征自行决定。这也是它被设计成注册变量级别开关的原因之一。
启用opt_enable_partial_data_modeling的具体方法
这个参数属于DB2的注册变量（Registry Variable），需要通过db2set命令设置。设置注册变量前，建议先查看当前值，确认是否已经启用过。操作步骤如下：首先以实例所有者身份登录，停止正在运行的相关应用连接（可选但推荐），然后执行设置命令并重启实例使配置生效。下面给出完整的命令序列。
-- 查看当前注册变量中与优化器相关的设置 db2set -all -- 启用部分数据建模 db2set DB2_OPT_ENABLE_PARTIAL_DATA_MODELING=ON -- 重启实例使设置生效 db2stop force db2start -- 验证设置是否已写入 db2set DB2_OPT_ENABLE_PARTIAL_DATA_MODELING
设置完成后，可以通过EXPLAIN捕获访问计划来验证效果。对比启用前后的计划，重点观察基数估计值（Estimated Cardinality）的变化。如果启用后估计值明显更接近实际返回行数，说明建模生效了。验证示例如下：
-- 先设置解释表（如尚未创建）
CALL SYSPROC.SYSINSTALLOBJECTS('EXPLAIN','C',NULL,CURRENT SCHEMA)
-- 对目标查询进行解释
SET CURRENT EXPLAIN MODE EXPLAIN;
SELECT order_id, customer_id
FROM orders
WHERE status = 'COMPLETE'
AND create_time < DATE('2024-01-01');
SET CURRENT EXPLAIN MODE NO;
-- 查看基数估计
SELECT * FROM EXPLAIN_OPERATOR WHERE OPCODE IN (31, 32);
除了注册变量本身，效果还依赖于统计信息的质量。建议同时收集列组统计信息，让建模有数据可用。RUNSTATS的调用方式如下：
-- 收集orders表的详细统计信息，包含status和create_time的列组 RUNSTATS ON TABLE db2inst1.orders WITH DISTRIBUTION AND DETAILED INDEXES ALL SET PROFILE;
如果只想在会话级别试验效果而不影响全局，可以配合SET CURRENT QUERY OPTIMIZATION调整优化级别，在较低的优化级别下对比测试。不过要注意，部分建模能力本质上是注册变量级别的开关，无法做到仅对单个会话生效，这一点和优化级别不同，规划变更窗口时要留意。
适用场景分析与风险控制
从实践来看，启用部分数据建模最适合的场景是：查询以分析型为主、SQL文本复杂、谓词之间存在相关性、且单条查询的执行成本远高于编译成本。典型的包括报表系统、BI查询、批处理作业等。这类查询编译一次可能执行很长时间，花额外的编译开销换取更准确的计划是划算的。
相反，如果是高并发的OLTP系统，大量短查询以毫秒级响应为目标，编译开销占比很高，贸然启用可能带来CPU使用率上升。另外，建模过程会增加优化器内存的使用，如果实例的SHEAPTHRES_SHR或相关内存参数配置得比较紧张，需要同步评估内存余量，避免出现编译排队甚至SQL0955N这类内存不足的错误。
变更后的观察期也建议做好。可以重点关注几个指标：一是db2pd -dynamic中动态语句的编译时间变化；二是监控快照中num_executions与rows_read的比例是否改善；三是通过db2pd -optimizer评估实际的建模行为。如果发现某些SQL的编译时间涨幅明显而计划没有实质改善，可以在测试环境回退变量，或者针对个别语句使用优化PROFILE固定计划，实现精细控制。
最后提醒一点，注册变量的调整属于实例级变更，务必先在测试环境验证，再安排到维护窗口应用到生产。变更后要保留启用前后的EXPLAIN输出作为基线，方便出现性能回退时快速定位。只要按照先评估负载特征、再小范围验证、最后观察上线的节奏来操作，opt_enable_partial_data_modeling就能在合适的场景下发挥出应有的价值。
DB2opt_enable_partial_data_modeling数据建模修改时间：2026-09-06 15:48:39