WITH子句仅在中间结果集被引用≥2次时才可能提速，否则仅为语法糖；加/+ MATERIALIZE /可能因物化开销反而变慢。
子查询因子化（WITH子句）在Oracle 21c中不是自动加速报表的银弹；它是否提速，完全取决于你是否多次引用同一中间结果集，以及是否配合MATERIALIZE提示控制物化行为。
什么时候WITH子句真能降低执行时间？
核心判断标准只有一条：同一个逻辑结果集在主查询中被引用≥2次。比如聚合后用于HAVING过滤、又用于子查询中的中位数计算、再用于ORDER BY——这时Oracle才可能从“反复执行”转向“算一次存起来”。
- 典型场景：
WITH sales_summary AS (SELECT region, SUM(sales) s FROM fact_sales GROUP BY region)，后续在WHERE、HAVING、ORDER BY里都用到了sales_summary - 反例：只在主查询
FROM里引用一次，且该子查询本身无聚合/连接开销，此时WITH只是语法糖，甚至因强制物化临时表而变慢 - Oracle 21c默认行为更激进：即使没加
MATERIALIZE，优化器也可能基于成本估算自动物化——但这个决策不可控，必须看EXPLAIN PLAN里的TEMP TABLE TRANSFORMATION操作符
为什么加了/*+ MATERIALIZE */反而查得更慢？
因为物化意味着写磁盘（或PGA临时段），再读取。当结果集小（
- 常见错误：对
SELECT * FROM customers WHERE status = 'ACTIVE'这种轻量过滤加MATERIALIZE，尤其当customers有status索引时 - 性能陷阱：物化过程不走并行，但原查询可能并行执行；一旦物化，整个链路退化为串行
- 验证方式：执行后查
V$SQL_PLAN，确认OPERATION列是否含LOAD AS SELECT，并对比BYTES和COST是否显著升高
如何让WITH子句在21c中真正可控地加速？
关键不是堆砌WITH，而是用提示+统计信息锚定执行路径。Oracle 21c对CTE的优化器干预能力比旧版本更强，但需要显式引导。
- 强制内联（避免物化）：
/*+ INLINE */放在子查询定义后，例如：WITH cust AS (SELECT /*+ INLINE */ cust_id FROM customers WHERE country = 'CN') - 强制物化（仅当确定需复用）：
/*+ MATERIALIZE NO_MERGE */，NO_MERGE防止优化器把子查询展开回主查询 - 必须同步更新统计信息：
DBMS_STATS.GATHER_TABLE_STATS对所有涉及的基表执行，否则优化器无法准确估算物化收益 - 注意21c新行为：如果子查询含
JSON_VALUE或VECTOR_DISTANCE等新函数，物化可能失败，报错ORA-30926: unable to get a stable set of rows，此时只能改用内联
递归CTE在报表场景下的实际限制
Oracle 21c支持递归WITH替代CONNECT BY，但报表类查询极少需要——除非你在生成动态日期序列、组织架构下钻、或自定义层级聚合（如按产品大类→子类→SKU逐级汇总）。普通销售日报、客户分群这类需求，递归反而增加复杂度和风险。
- 性能红线：递归深度超过100层时，21c默认抛
ORA-01436: CONNECT BY loop in user data，需设MAXDEPTH参数，但会截断数据 - 调试难点：递归CTE的执行计划无法像普通CTE那样清晰分段，
DBMS_XPLAN输出里RECURSIVE WITH PUMP节点掩盖真实I/O消耗 - 替代方案更稳：用
GENERATE_SERIES（21c新增）生成日期维度，或预建层级表+JOIN，比递归CTE更易维护、更可预测
真正影响大规模报表速度的，从来不是“用了WITH没”，而是“物化时机是否匹配数据访问模式”。21c的优化器足够聪明，但不会替你做业务判断——它只认统计信息、提示、和执行计划里那些冷冰冰的COST数字。
