DB2子查询使用视图性能比直接复制视图内容慢30%，求优化方案

针对你遇到的视图查询比直接复制SQL慢30%的问题，给你几个实用的解决办法：

• 更新统计信息
  DB2优化器依赖统计信息生成最优执行计划，如果视图或它依赖的底层表统计信息过时，就可能选到低效的执行路径。直接执行以下命令更新：

-- 更新视图关联的底层表统计，替换为实际表名
RUNSTATS ON TABLE 底层表名 WITH DISTRIBUTION AND DETAILED INDEXES ALL;
-- 部分DB2版本支持直接更新视图统计
RUNSTATS ON VIEW view_vc;

如果视图关联多个表，每个表都需要执行一次更新操作。

• 改用物化视图（MQT）
  普通视图每次查询都会重新计算逻辑，物化视图会预先计算并存储结果，查询时直接读取现成数据，能显著提升速度。创建语句参考：

-- 复制view_vc的完整定义到括号内
CREATE TABLE mqt_vc AS (
    SELECT ref, ... -- 这里是view_vc的完整SQL逻辑
    FROM ...
    WHERE ...
) DATA INITIALLY DEFERRED REFRESH DEFERRED;

-- 手动刷新物化视图数据
REFRESH TABLE mqt_vc;

之后把查询里的view_vc替换为mqt_vc即可，还可以添加REFRESH EVERY 1 HOUR这类配置实现定时自动刷新。

• 改写查询为JOIN方式
  IN子查询有时会限制优化器对主表和视图的联合优化能力，改成JOIN写法试试：

SELECT DISTINCT abc.*
FROM abc
JOIN view_vc vc ON abc.ref_id = vc.ref
WHERE abc.id = 1;

DISTINCT是为了避免重复数据，若你的业务数据本身不会重复，可直接去掉。

• 简化视图定义
  检查view_vc的SQL逻辑，看看有没有冗余的DISTINCT、没必要的函数嵌套，或是可以提前过滤的条件，简化后视图本身的执行效率也会提升。

• 强制优化器展开视图
  有时候DB2不会自动将视图逻辑与主查询合并优化，导致分开执行视图再匹配数据，加个优化提示强制展开视图：

SELECT *
FROM abc
WHERE id = 1
AND ref_id IN (
    SELECT ref FROM view_vc /*+ EXPAND_VIEW(view_vc) */
);

注意不同DB2版本对优化提示的支持可能有差异，先测试再正式使用。

• 检查并优化索引
  看看abc表有没有id+ref_id的组合索引，view_vc依赖的表有没有ref字段的索引，合适的索引能大幅降低查询耗时，比如给abc建组合索引：

CREATE INDEX idx_abc_id_ref ON abc(id, ref_id);

内容的提问来源于stack exchange，提问作者db2