在DB2数据库的性能调优工作中，基数估算的准确性直接决定了优化器能否生成高质量的执行计划。当表中某个列存在数据倾斜（skew），也就是某个或某几个值出现的次数远超其他值时，优化器如果只依赖基础的统计信息，很容易做出错误判断。DB2提供的opt_freqval_stats注册变量正是为了解决这类频繁值（frequent value）统计问题而设计的。本文将系统讲解这个参数的原理、配置方式和实际效果。
一、为什么需要频繁值统计：数据倾斜带来的基数估算问题
要理解opt_freqval_stats的作用，首先需要弄清楚DB2优化器是如何估算查询基数（cardinality estimation）的。在默认情况下，如果优化器只掌握表级统计信息（行数、页数）和列级的基本统计信息（如列的COLCARD，即不同值的个数），它会假设数据是均匀分布的。也就是说，某个等值谓词的过滤因子会被估算为1/COLCARD。
这种假设在数据均匀分布时问题不大，但现实业务数据往往存在明显倾斜。举个例子，一张订单表有一千万行数据，其中status列有10个不同值，均匀分布假设下每个值的过滤因子是10%。可实际情况可能是status='已完成'占了95%的行，而status='已取消'只占不到1%。当查询条件是status='已取消'时，优化器估算出一百万行，实际却只有几万行，这就可能导致本应使用索引的场景却选择了全表扫描，或者连接顺序和连接方式的选择出现严重偏差。
为了解决这一问题，DB2提供了两类手段：一类是收集列组统计信息（column group statistics），另一类就是频繁值统计。opt_freqval_stats属于注册变量（registry variable），它控制优化器在使用RUNSTATS收集的频繁值信息时的行为，让基数估算能够反映真实的数据分布。
二、opt_freqval_stats的取值含义与配置方法
opt_freqval_stats是一个DB2注册变量，需要在数据库管理器级别设置，并通过重启实例生效。它主要有以下几个取值档位，不同档位决定了优化器对频繁值信息的利用程度：
- 未设置（默认）：优化器在基数估算中有限度地使用频繁值信息，行为遵循传统的估算模型。
- ON 或 1：允许优化器在谓词引用频繁值时，直接使用频繁值统计中的实际频率代替均匀分布假设，同时会考虑多次谓词组合时频繁值的处理方式。
- ALL 或 2：更激进的模式，对所有适用的场景（包括连接谓词、本地谓词组合等）都尽量利用频繁值信息进行基数修正，估算精度更高，但优化器在编译复杂查询时的开销也会相应增加。
设置和查看该变量的基本操作如下：
-- 设置注册变量（以ON为例） db2set DB2_OPTIMIZATIONPROFILE= db2set OPT_FREQVAL_STATS=ON -- 查看当前设置 db2set -all -- 重启实例使设置生效 db2stop force db2start
需要注意的是，注册变量的作用范围是实例级的，会影响该实例下所有数据库的优化器行为。在生产环境启用之前，建议先在测试环境充分验证。此外，为了让该变量真正发挥作用，前提是必须通过RUNSTATS收集到包含频繁值的统计信息，否则优化器手里没有数据，参数开得再高也无济于事。
三、配合RUNSTATS收集频繁值统计信息
opt_freqval_stats只是告诉优化器如何利用频繁值信息，而信息本身要靠RUNSTATS来采集。使用WITH DISTRIBUTION选项可以让DB2在收集基础统计的同时，额外采集数据分布信息，包括分位数（quantiles）和频繁值（frequent values）。
一个典型的收集语句如下：
-- 对表和索引收集带分布信息的统计
RUNSTATS ON TABLE ORDERS
WITH DISTRIBUTION ON COLUMNS (STATUS, CUSTOMER_ID)
AND DETAILED INDEXES ALL
ALLOW WRITE ACCESS;
-- 控制频繁值数量和精度
RUNSTATS ON TABLE ORDERS
WITH DISTRIBUTION ON COLUMNS (
STATUS NUM_FREQVALUES 10 NUM_QUANTILES 20,
CUSTOMER_ID NUM_FREQVALUES 50 NUM_QUANTILES 50
);
其中NUM_FREQVALUES指定为每列保留多少个最频繁的值，NUM_QUANTILES指定分位数的个数。对于倾斜明显的列，适当增大频繁值数量可以提升估算精度，但也会增加目录表（SYSSTAT.COLDIST）的存储和统计收集的时间。可以通过查询SYSSTAT.COLDIST视图来确认频繁值是否已经收集到位：
-- 查看某列的频繁值统计 SELECT COLNAME, TYPE, SEQNO, VALCOUNT, LOWVALUE, HIGHVALUE FROM SYSSTAT.COLDIST WHERE TABSCHEMA = 'SALES' AND TABNAME = 'ORDERS' AND COLNAME = 'STATUS' AND TYPE = 'F' ORDER BY VALCOUNT DESC;
查询结果中TYPE为F的行就是频繁值记录，VALCOUNT是该值在表中的实际出现次数。如果查不到记录，说明RUNSTATS没有带WITH DISTRIBUTION执行，需要重新收集。
四、实际案例：启用前后的执行计划对比
某业务系统中存在一条典型的查询，订单表有8000万行，查询条件包含status='已取消'和customer_id的等值条件。启用opt_freqval_stats之前，优化器按照均匀分布假设，将status的过滤因子估为约8%，估算中间结果集达数百万行，于是放弃了status列上的索引，选择全表扫描后再做hash连接，整体执行时间超过90秒。
收集分布统计并启用变量之后，优化器从频繁值统计中得知status='已取消'只占0.4%的行，基数估算大幅下降，执行计划改为先通过status索引扫描，再回表关联customer_id，整体执行时间降到3秒以内。这个案例说明，频繁值统计的价值不在于参数本身，而在于让优化器拿到了接近真实的数据分布画像。
验证执行计划变化时，可以使用db2expln或db2exfmt工具对比前后的估算行数（Estimated Rows）与实际行数，如果两者差距在一个数量级以内，通常说明基数估算已经比较可靠。
-- 导出解释信息并格式化 db2 "SET CURRENT EXPLAIN MODE EXPLAIN" db2 "SELECT ... " db2exfmt -d SAMPLE -1 -o plan_after.txt
五、注意事项与常见问题排查
首先，统计信息的时效性非常关键。数据分布会随时间变化，如果频繁值统计已经过期，优化器可能基于错误的频率做决策，效果反而不如均匀假设。建议对倾斜明显的核心表建立定期RUNSTATS任务，或者在大量数据变更后手动触发统计收集。
其次，启用opt_freqval_stats后可能引起部分SQL执行计划变化，个别原本正常的查询也许会退化。这是因为优化器改变了估算模型，极少数场景下统计信息本身存在偏差。遇到这种情况，不要急于回退参数，应先用解释工具分析退化语句的估算基数是否合理，必要时调整NUM_FREQVALUES重新收集统计，或者对个别语句使用优化概要文件（optimization profile）固定计划。
最后需要提醒的是，该变量是实例级设置，多数据库共存的实例上改动要评估影响面。任何优化参数都不是银弹，频繁值统计解决的是数据倾斜导致的估算失真问题，如果系统瓶颈在I/O、锁等待或内存配置上，还需要从其他维度综合排查。建议每次变更都遵循在测试环境验证、灰度上线、持续观察重点SQL响应时间的流程，把优化工作做得稳妥可控。
DB2opt_freqval_stats频繁值统计修改时间：2026-09-11 20:06:44