在DB2的日常调优工作中，视图引起的性能问题经常被忽视。不少DBA遇到过这样的情况：同一条查询逻辑，直接写基表的SQL执行只要几百毫秒，换成查视图就要跑好几秒。排查索引、检查锁等待都一无所获，最后打开执行计划才发现，优化器对视图结果的行数估算严重失真。这背后往往和opt_view_stats这个数据库配置参数有关，它直接影响优化器在处理引用视图的语句时能否正确利用统计信息。
opt_view_stats参数的作用机制
要理解这个参数，先要明白DB2优化器的工作方式。优化器在为一条SQL生成访问计划时，需要对每一步操作的输出行数做基数估算，估算的依据就是系统目录表SYSCAT.TABLES、SYSCAT.COLUMNS、SYSCAT.INDEXES中保存的统计信息，比如CARD（行数）、NPAGES（页数）、高频值等。对于基表，这些信息通过RUNSTATS命令收集，优化器可以直接使用。
但视图本身并不存储数据，它只是一条被命名的SELECT语句。当查询引用视图时，优化器理论上可以把视图定义展开，与外层查询合并后统一优化，这种情况下基表统计信息天然可用。问题出在视图无法被完全合并的场景，比如视图里包含GROUP BY、DISTINCT、UNION或者某些聚合函数，此时视图部分会作为独立的估算单元，优化器需要单独估算这个中间结果集的规模。
opt_view_stats参数正是控制这一行为的开关。当它被设置为ON时，优化器会尝试利用视图基表上已有的统计信息来推算视图结果集的基数和谓词选择性，而不是简单套用默认的估算规则。在DB2的较新版本中，配合自动表表达式的统计概要，视图估算的精度可以大幅提升。当参数为OFF时，优化器对无法合并的视图部分只能采用相对保守的固定公式估算，一旦视图定义复杂、过滤条件多，估算偏差就会层层放大，最终导致连接顺序、连接方法乃至索引选择全部出错。
如何查看和修改opt_view_stats
< p>这个参数属于数据库配置参数，查看和修改都很简单，可以通过命令行完成。-- 查看当前数据库配置，确认opt_view_stats的取值 db2 get db cfg for sample | grep -i opt_view_stats -- 开启视图统计推算功能 db2 update db cfg for sample using opt_view_stats on -- 如果需要恢复默认行为，可以关闭 db2 update db cfg for sample using opt_view_stats off
修改配置参数后，要注意一点：参数变更只影响新生成的访问计划，已经编译并缓存在包缓存中的静态语句不会自动重编译。如果想让存量SQL也受益，需要刷新包缓存或者对相关存储过程、静态SQL包执行rebind操作，命令如下。
-- 刷新动态语句缓存，让后续执行重新编译 db2 flush package cache dynamic -- 对指定包重新绑定，让静态SQL重新生成访问计划 db2 rebind package SCHEMA001.P1234567 resolve any
另外建议把参数修改与统计信息收集一起做。opt_view_stats只是允许优化器去用统计信息，如果基表本身的统计信息过期甚至从未收集过，参数开了也没有意义。典型的配合方式是先对视图涉及的所有基表执行RUNSTATS，再开启参数，最后刷新缓存，一次性完成闭环。
实际案例对比与常见问题排查
举一个实际遇到的例子。某业务系统有一个销售汇总视图，内部包含GROUP BY聚合和三个基表的连接，外层查询在视图上再按日期过滤。参数未开启时，执行计划中该视图的估算行数显示为固定值，实际返回约两万行而估算只有几十行，优化器据此选择了嵌套循环连接并放弃了可用索引，整体执行八秒多。开启opt_view_stats并对基表重新收集统计信息后，估算行数修正到一万八千左右，优化器改为哈希连接并正确使用了日期索引，执行时间降到六百毫秒。可以通过EXPLAIN工具直接观察前后差异。
-- 使用EXPLAIN观察视图部分的基数估算 SET CURRENT EXPLAIN MODE EXPLAIN; SELECT * FROM SALES_SUMMARY_V WHERE ORDER_DATE BETWEEN '2024-01-01' AND '2024-06-30'; SET CURRENT EXPLAIN MODE NO; -- 查看生成的访问计划 db2exfmt -d sample -1 -o plan_after.txt
排查这类问题时有几个常见坑值得注意。第一，视图定义里如果包含对易变函数的调用，比如某些随机或时间敏感的函数，即使开启参数优化器也难以准确估算，这类视图应尽量改写。第二，多层的嵌套视图会让估算误差叠加，建议对深层嵌套的视图做扁平化重构，或者将中间结果物化到MQT（物化查询表）中，MQT支持独立的统计信息收集，估算精度比普通视图更可控。第三，修改参数后没有刷新包缓存是反馈最多的问题，很多人以为参数不生效，实际上是旧执行计划还在缓存里运行。
总结一下，opt_view_stats的价值在于让优化器对不可合并的视图也能做出有数据支撑的基数估算。它不是万能开关，生效的前提是基表统计信息及时、视图定义不过分复杂。调优时按收集统计信息、开启参数、刷新缓存这个顺序操作，再用EXPLAIN验证估算值是否回到合理区间，视图慢查询的问题基本都能定位并解决。
DB2opt_view_stats视图统计修改时间：2026-09-14 05:58:32