在DB2的优化器体系里，基数估算的准确程度直接决定了执行计划的好坏。当查询涉及的表缺少统计信息，或者统计信息过于陈旧时，优化器往往只能按默认规则瞎猜，导致选错连接方式、走错索引，SQL性能断崖式下降。DB2为此提供了一个注册表变量DB2_OPT_ENABLE_PARTIAL_DATA_DRIVEN，允许优化器利用查询中已经可用的部分数据特征来驱动估算，哪怕只有一部分表具备完整的统计信息，也能做出更接近真实的判断。
这个参数并不是DB2默认开启的能力，需要DBA在理解其工作机制后有针对性地启用。本文从原理、配置方法、典型场景和风险控制四个角度，把这个参数讲透。
什么是部分数据驱动，它的底层原理是什么
所谓数据驱动估算，指的是优化器不再完全依赖RUNSTATS采集的目录统计信息，而是结合查询执行前能够获取到的实际数据特征，比如过滤列的取值分布、谓词的选择性等，来修正基数估算。传统的估算流程是纯静态的：优化器读取SYSCAT.STATISTICS等目录视图中的统计值，套用公式算出每个谓词的过滤比例，再逐步推算整个查询的中间结果集大小。一旦统计信息过期或者根本没采集过，这些公式就只能使用默认的选择性，通常是假设谓词过滤掉三分之一的行，结果自然离谱。
部分数据驱动的关键在于部分两个字。在复杂查询里，往往不是所有表都缺统计信息，可能十张表里有八张的统计信息是新的，只有两张刚做过大批量装载还没来得及RUNSTATS。如果因为这两张表就导致整体估算失真，进而让连接顺序和连接方法全错，代价非常高。启用DB2_OPT_ENABLE_PARTIAL_DATA_DRIVEN之后，优化器可以对统计信息完整的那部分表采用数据驱动的精确估算，对缺失统计信息的表沿用保守默认值，两者混合，整体计划的可靠性会明显提升。
从实现机制上看，这个变量影响的是优化器在编译期做基数推导时的策略选择。开启后，优化器在遇到统计信息缺口时，会更积极地去评估是否可以通过采样、列组统计、已有的分布统计等手段来弥补，而不是简单地退化到默认选择性。对于包含复杂谓词组合的查询，比如多个AND条件、IN列表、LIKE前缀匹配等场景，这种混合估算策略的效果尤其明显。
如何启用和验证参数配置
这个参数属于DB2注册表变量，需要通过db2set命令设置。它可以在实例级别生效，也可以针对单个实例全局设置。设置之后不需要重启实例，但已编译好的SQL包不会自动重新优化，需要让相关的动态SQL重新编译，或者对静态SQL执行REBIND。
具体的操作命令如下：
-- 查看当前设置 db2set DB2_OPT_ENABLE_PARTIAL_DATA_DRIVEN -- 在实例级别启用 db2set DB2_OPT_ENABLE_PARTIAL_DATA_DRIVEN=ON db2 terminate
设置完成后，建议先用一条存在性能问题的SQL验证效果。通过EXPLAIN获取优化前后的执行计划，重点对比基数估算值和实际返回行数的偏差。验证脚本可以参考下面的方式：
-- 生成执行计划 EXPLAIN ALL FOR SELECT e.empno, d.deptname FROM employee e JOIN department d ON e.workdept = d.deptno WHERE e.salary > 50000 AND d.location = 'NEW YORK'; -- 查看估算基数 SELECT operator_id, total_cost, row_count FROM explain_operator WHERE explain_requester = 1 ORDER BY total_cost DESC;
如果开启参数后，计划中某些JOIN操作符的估算基数更接近实际行数，成本模型给出的连接顺序更合理，SQL的实际执行时间明显缩短，说明这个参数对当前工作负载是有正收益的。反过来，如果计划没有变化，可能是涉及的查询本身统计信息齐全，数据驱动机制没有触发点，这种情况保持参数开启也无害，只是没有收益而已。
适用场景与典型案例
第一个典型场景是ETL批量装载后的查询窗口。很多数据仓库在夜里做大批量数据装载，如果装载后没有及时跑RUNSTATS，第二天上午的高峰查询就会撞上统计信息缺失的问题。这类环境里启用部分数据驱动，可以让还没刷新统计信息的表不至于把整条查询的估算全部带偏，为DBA争取补采统计信息的时间。
第二个场景是查询涉及大量临时中间结果或者未采集分布统计的列。比如某些过滤列上只有基础的表级统计，没有列级分布信息，优化器对WHERE条件的判断完全靠猜。数据驱动机制会参考可用的部分特征来修正这些判断，让类似查询的计划稳定性提高。
第三个场景是第三方应用生成的动态SQL。这类SQL无法修改写法，也无法针对性建统计，只能靠优化器自身的策略调整来兜底。开启这个参数相当于给优化器多了一个可用的估算工具，属于不动应用代码就能改善性能的低成本手段。
-- 典型的补救措施：配合统计信息刷新 RUNSTATS ON TABLE myschema.sales ON ALL COLUMNS WITH DISTRIBUTION ON ALL COLUMNS AND SAMPLED DETAILED INDEXES ALL;
需要强调的是，这个参数不能替代RUNSTATS。它是统计信息不完善时的缓解手段，而不是长期方案。根本上还是要建立定期统计信息采集机制，把参数作为兜底保障。
风险控制与调优建议
任何影响优化器行为的参数都有两面性。数据驱动估算虽然在多数情况下让估算更准，但它也会增加SQL编译期的工作量，对于高并发的短小查询，编译时间的变化会直接体现为CPU开销的上升。因此在OLTP高频交易环境中启用前，建议先在测试环境用真实负载回放验证，观察编译时间占比的变化。
另一个风险是计划波动。开启后同一批SQL在不同时间点的估算依据可能不同，执行计划出现抖动的概率会上升。如果系统对计划稳定性要求极高，可以配合DB2的计划管理能力，通过设置DB2_WORKLOAD相关的配置或者使用优化概要文件来固定关键SQL的计划，只让非关键查询享受数据驱动的收益。
回退方案也很简单。如果发现开启后整体性能不升反降，直接用db2set把变量设回OFF，执行db2 terminate让连接重新读取注册表，再对关键包做REBIND即可恢复。建议在变更窗口操作，并保留开启前后的执行计划快照，便于对比确认参数的真实影响。
总结来说，DB2_OPT_ENABLE_PARTIAL_DATA_DRIVEN是一个针对统计信息不完整场景的优化器增强开关。它适合数据仓库、批处理系统、统计信息更新不及时的环境，配合RUNSTATS策略一起使用效果最佳。启用前做好测试验证，启用后持续监控计划质量和编译开销，才能把这个冷门参数的价值真正发挥出来。