Oracle 19c默认对满足条件的UNION ALL查询自动启用子查询因式分解，但仅当CBO估算成本更低时才实际应用，非无条件开启，也不受optimizer_features_enable控制。
子查询因式分解在Oracle 19c中是否自动启用
Oracle 19c 默认对满足条件的 UNION ALL 查询启用子查询因式分解（Join Factorization），但仅当优化器估算其成本更低时才实际应用。它不是无条件开启的，也不受 optimizer_features_enable 控制，而是由 CBO 基于统计信息和代价模型动态决定。
常见误判点：看到执行计划里有 VW_JF_SET$xxxx 视图名，就认为“已启用”，其实这只是因式分解后的内联视图别名；真正生效要看该视图是否被复用、是否减少了重复扫描。
- 必须是
UNION ALL，UNION或INTERSECT不触发 - 各分支中需存在可提取的公共表+公共谓词（如都访问
t1且都有t1.status = 'A'） - 不能含不兼容结构：如某分支有
GROUP BY、DISTINCT、或相关子查询未展开 - 若用了
/*+ no_merge */或/*+ no_push_pred */等阻止合并的 hint，会抑制因式分解
如何确认执行计划中发生了子查询因式分解
关键看执行计划中是否出现形如 VW_JF_SET$... 的物化中间视图，且该视图被多个分支共用 —— 这表示优化器已把公共部分提前计算一次，再分别连接剩余逻辑。
典型线索：
- Plan 中存在
VIEW操作，Name 列为VW_JF_SET$... - 该
VIEW的子节点是多个UNION-ALL分支的公共表扫描（如全表扫T1+ 索引查T2） - 后续各分支通过
HASH JOIN或NESTED LOOPS接入这个VIEW，而非各自重复扫描相同表
反例：如果每个 UNION ALL 分支都独立走一遍 T1 全表扫描，说明因式分解未发生 —— 可能因统计信息陈旧、分支间谓词差异过大，或存在隐式类型转换干扰匹配。
手动干预因式分解的常用手段
当 CBO 拒绝因式分解但人工判断收益明显时，可尝试以下方式引导：
- 用
/*+ use_concat */配合重写为等价OR条件（适用于简单分支），有时比UNION ALL更易触发公共提取 - 显式提取公共逻辑为 WITH 子句（
WITH common AS (...) SELECT ... FROM common JOIN ... UNION ALL SELECT ... FROM common JOIN ...），绕过优化器自动识别限制 - 确保所有分支中涉及的列名、数据类型、NULL 性完全一致，避免因隐式转换导致分支无法归一化
- 更新涉及表的统计信息，尤其是
NUM_DISTINCT和NUM_NULLS，CBO 对公共谓词选择性估算不准时会放弃因式分解
注意：/*+ no_factorize_join */ 是禁用该优化的唯一官方 hint，但没有“强制启用”的 hint —— Oracle 不提供硬性开关。
因式分解失败的典型场景与规避建议
最常卡在“看似能提，实则提不了”的地方：比如一个分支过滤 t1.id IN (SELECT id FROM t3)，另一个分支是 t1.id = :bind，表面都查 t1.id，但子查询的存在让优化器无法将 t1 提到外层公共部分。
- 相关子查询未展开（如
EXISTS (SELECT 1 FROM t4 WHERE t4.x = t1.y)）会阻断因式分解，可加/*+ unnest */尝试展开 - 分支间连接顺序不一致（如分支1是
t1 JOIN t2，分支2是t2 JOIN t1）可能导致匹配失败，统一书写顺序有助于识别 - 分区表上跨分区的
UNION ALL若各分支访问不同分区键范围，CBO 可能放弃提取，此时改用分区剪枝友好的谓词更有效
真正难调的不是“怎么启”，而是“为什么没启”——得盯着 VW_JF_SET$ 是否出现、它的输入是否真被复用、各分支的 Predicate Information 是否收敛到同一过滤条件。漏掉任一环，都可能白做半天调整。
