DB2优化器选取访问路径时非常依赖统计信息的准确性。对于普通单表查询，只要RUNSTATS及时收集，基数估计一般不会偏差太大。但SQL一旦涉及子查询，尤其是相关子查询、多层嵌套子查询或者子查询内部存在表达式计算时，优化器对子查询返回行数的估算就容易失真。一旦子查询基数被高估或低估，外层表就可能从索引扫描切换成全表扫描，或者从哈希连接切换成嵌套循环，最终导致整条SQL性能下降。opt_subq_stats就是DB2提供给优化器的一个补充统计开关，专门用来改善子查询场景下的估算质量。
这个参数的核心价值在于让优化器不再只依赖外层查询的统计信息，而是对子查询内部的过滤条件、分组列、连接谓词和表达式结果进行更深入的分析。文章会从参数作用机制、启用验证方法、实际案例和注意事项几个角度展开，帮助读者判断它是否适合当前业务系统中那些子查询相关的慢SQL。
opt_subq_stats到底控制了什么
在默认情况下，DB2优化器处理子查询时，通常会先把子查询当作一个独立的查询块进行估算，然后将估算结果代入外层查询。这个过程看似合理，但问题在于子查询内部的谓词组合往往非常复杂。比如子查询中同时存在多个条件：状态字段等值过滤、日期范围过滤、字符串函数转换以及与其他表的关联条件。优化器如果没有足够的细节统计，就可能采用简单的选择率相乘方式来计算最终返回行数，这在高关联性列或者倾斜数据分布下会产生明显误差。
opt_subq_stats的作用就是允许优化器在编译阶段对子查询中的关键表达式和局部谓词生成额外的统计信息。它不会替代RUNSTATS已经收集的表级和索引级统计信息，而是在此基础上进行二次细化。比如一个子查询包含 UPPER(status) = 'ACTIVE' 这样的条件，普通统计可能无法准确反映函数作用后的选择率，开启该参数后，优化器有条件对这类表达式做更合理的估算。类似地，子查询内部的 GROUP BY 列如果存在严重倾斜，优化器也能获得更接近真实分布的基数信息。
还需要区分两类子查询：非相关子查询和相关子查询。非相关子查询只执行一次，估算偏差主要影响子查询结果集大小；相关子查询会被外层每一行反复驱动，基数偏差会被成倍放大。因此，相关子查询场景下优化器如果没有准确的局部统计，执行计划往往会非常脆弱，很小的数据变化都可能导致计划翻转。opt_subq_stats在这类场景中更有价值，因为它能降低优化器对外层行数和内层谓词组合的敏感度。
如何启用opt_subq_stats并验证是否生效
不同DB2版本中，该参数可能以注册变量或者数据库配置参数的形式出现。较常见的方式是通过注册变量启用，变量名通常写作 DB2_OPT_SUBQ_STATS。在Linux或Unix环境下，可以使用以下命令查看当前值：
db2set -all | grep -i subq
如果当前没有设置该变量，输出中不会显示相关行。启用时执行：
db2set DB2_OPT_SUBQ_STATS=ON db2 terminate db2stop db2start
设置完成后需要重启实例，仅重新连接通常无法加载新的注册变量值。如果使用的是数据库配置参数形式，可以用类似下面的命令开启：
db2 update db cfg for sample using opt_subq_stats ON db2 connect reset db2 activate db sample
参数生效后，重新收集一次相关表的RUNSTATS并不是强制要求，但如果表数据已经发生较大变化，建议先执行 RUNSTATS ON TABLE ... WITH DISTRIBUTION AND DETAILED INDEXES ALL，再让优化器使用新参数进行子查询统计细化。这样能保证基础统计是可靠的，opt_subq_stats的增量优化才有意义。
验证参数是否对计划产生了影响，最好的方式是对目标SQL执行explain。可以先关闭参数生成一份计划，再开启参数生成另一份计划，对比子查询部分的基数估算和访问路径。使用 db2exfmt 输出格式化计划时，重点查看子查询节点附近的估算行数、实际行数估计以及谓词选择率。如果发现开启后子查询估算行数从几十万下降到几千，或者外层表从表扫描变成索引扫描，就说明参数确实参与了优化器决策。
典型优化场景与效果对比
举一个常见的业务查询例子。假设有一张订单表 orders 和一张客户表 customer，需要查询东部区域VIP客户的订单：
SELECT o.order_id, o.order_date, o.amount
FROM orders o
WHERE o.cust_id IN (
SELECT c.cust_id
FROM customer c
WHERE c.region = 'EAST'
AND c.level = 'VIP'
);
如果 customer 表上存在 region 和 level 的复合索引，但没有收集列组分布统计，优化器可能分别计算两个单列谓词的选择率，然后相乘得到子查询返回行数。当东部区域客户占比很高，同时VIP客户占比也很高时，简单相乘会低估返回行数；如果两个条件高度重叠，也可能高估。无论哪种偏差，都会影响外层 orders 表的访问策略。
开启opt_subq_stats后，优化器会在子查询块内部尝试对 region='EAST' 和 level='VIP' 的组合条件进行评估，而不是机械相乘。配合RUNSTATS收集的列组统计，基数估算可以更接近实际数据分布。
| 对比项 | 开启前 | 开启后 |
|---|---|---|
| 子查询估算行数 | 约86万 | 约1.4万 |
| orders表访问方式 | 全表扫描 | 索引范围扫描 |
| 连接方式 | 嵌套循环 | 哈希连接 |
| 预估总成本 | 18342 | 237 |
从对比中可以看到，子查询基数下降后，优化器不再选择扫描整张订单表，而是通过索引先定位相关订单，再完成连接。这种变化对于大数据量表来说往往是数量级的性能提升。需要注意的是，优化效果并不是每次都会如此明显，如果子查询本身返回行数较大，或者外层表缺少合适索引，开启参数后计划可能保持不变。
另一个容易受益的场景是子查询中存在 EXISTS 或 NOT EXISTS。例如：
SELECT o.order_id
FROM orders o
WHERE EXISTS (
SELECT 1
FROM order_item i
WHERE i.order_id = o.order_id
AND i.item_status IN ('PENDING', 'HOLD')
);
这里的子查询是否快速结束取决于优化器对内层过滤条件的估算。如果 item_status 存在严重倾斜，比如大部分订单都有PENDING或HOLD记录，那么EXISTS子查询几乎每次都会命中，外层订单表的扫描方式就非常关键。opt_subq_stats可以让优化器更准确地判断子查询的命中比例，避免错误地选择先扫描订单表再逐行探测子查询。
使用注意事项与监控建议
opt_subq_stats虽然能改善统计质量，但也会增加SQL编译阶段的CPU开销。对于执行频率很高、但本身复杂度不高的简单SQL，开启后可能感知不到编译成本变化；对于批量复杂报表、动态SQL拼接场景，编译时间可能会略有增加。因此建议先在测试环境对核心SQL集进行回归，观察平均编译时间和执行时间的变化趋势，再决定是否推广到生产环境。
这个参数不能替代RUNSTATS。如果表已经很久没有收集统计信息，或者统计信息严重失真，那么开启opt_subq_stats也不会得到准确计划。优化器的任何细节估算都建立在基础统计之上，正确的做法是保持RUNSTATS周期执行，尤其对大表变化频繁的列组合及时收集 DISTRIBUTION 和 COLUMN GROUP 统计。
开启参数后，需要关注执行计划是否发生大幅翻转。对于已经通过 db2look 保存过基线计划的系统，可以在测试环境使用 db2batch 或事件监视器对比开启前后的SQL执行时间。如果发现某些关键SQL性能反而下降，可以针对单条SQL使用优化配置文件或者绑定参数进行局部控制，而不是全库关闭参数。也可以先设置 DB2_OPT_SUBQ_STATS=OFF 回退到原有行为，再分析具体原因。
最后，建议结合 SYSCAT.TABLES、SYSCAT.COLUMNS 和优化器统计信息视图定期检查子查询相关列的基础统计是否存在缺失。例如某些索引列没有直方图、某些组合条件没有收集列组统计，这些都会限制opt_subq_stats的发挥空间。只有当基础统计完整、参数开关正确、执行计划可以被解释和对比时，子查询统计优化才能真正落到实处。
DB2 opt_subq_stats子查询统计信息查询优化器修改时间：2026-10-02 02:55:51