Oracle 21c无optimizer_subquery_unnest参数，解嵌套由CBO基于统计信息、查询结构和提示自动决策；确认方式唯一看执行计划——出现HASH JOIN/NESTED LOOPS即已解嵌套，VIEW或FILTER则未解嵌套。
Oracle 21c 中没有“子查询解嵌套优化参数”可配置——它由优化器自动决定是否解嵌套，且不提供开关式参数控制。 你无法通过 ALTER SYSTEM 或修改 optimizer_mode 来强制开启/关闭子查询解嵌套。真正影响行为的是统计信息质量、查询结构和显式提示，而非某个隐藏开关。
为什么找不到 optimizer_subquery_unnest 参数？
Oracle 从未在任何版本（包括 21c）中暴露名为 optimizer_subquery_unnest 的初始化参数。网上搜到的类似名称多是误传或混淆了内部调试事件（如 event 10141）。21c 的子查询解嵌套完全由 CBO 基于成本估算动态触发，依赖以下事实：
- 子查询是否相关（correlated）：非相关子查询更易被解嵌套
- 外层 WHERE 或 JOIN 条件能否下推到子查询中（例如将
t1.id IN (SELECT t2.id FROM t2)转为t1 JOIN t2 ON t1.id = t2.id） - 基表统计信息是否最新：若
DBMS_STATS.GATHER_TABLE_STATS未执行，优化器可能因行数误估而放弃解嵌套 - 是否存在阻断解嵌套的语法：如子查询含
ROWNUM、ORDER BY（无对应WINDOW）、聚合后未加GROUP BY等
如何确认子查询是否被解嵌套？
唯一可靠方式是看执行计划，不是查参数。重点关注 EXPLAIN PLAN 输出中的 OPERATION 列：
- 若看到
VIEW或UNION-ALL下挂子查询节点，说明未解嵌套（仍以视图方式执行） - 若原
WHERE ... IN (SELECT ...)变成NESTED LOOPS或HASH JOIN，说明已解嵌套 - 特别注意
IN-LIST ITERATOR或FILTER操作符：它们常代表未解嵌套的逐行检查，性能风险高
执行命令：EXPLAIN PLAN FOR SELECT ...; SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
能用什么提示干预解嵌套行为？
当默认行为不符合预期时，可用以下提示定向引导，但必须配合真实执行计划验证效果：
- 强制解嵌套：
/*+ UNNEST */加在子查询括号前，例如WHERE t1.x IN (SELECT /*+ UNNEST */ x FROM t2) - 禁止解嵌套：
/*+ NO_UNNEST */，适用于子查询结果集小、且外层驱动条件强的场景 - 配合半连接优化：
/*+ USE_HASH_SJ(t2) */或/*+ USE_NL_SJ(t2) */，在解嵌套后指定连接算法 - 注意：提示只对当前子查询生效；嵌套多层时需逐层标注，否则外层提示不传递
容易忽略的关键点
解嵌套不是万能加速器。在 21c 中，它可能因以下原因失效或变慢：
- 子查询含
JSON_VALUE或VECTOR_DISTANCE：这类函数在解嵌套路径中可能触发 ORA-30926 错误，只能退回到NO_UNNEST - 临时表空间压力大时，解嵌套产生的中间结果集若需物化（尤其带排序），会加剧 TEMP 段争用
- 并行查询中，解嵌套可能破坏原并行度：优化器有时将子查询转为串行执行再 join，导致整体退化
- 统计信息陈旧时，优化器可能高估子查询输出行数，从而错误选择嵌套循环而非哈希连接
最稳妥的做法不是调参，而是用 DBMS_STATS.GATHER_TABLE_STATS 更新所有涉及表，并用 EXPLAIN PLAN 对比加/不加提示的实际路径与 COST 差异。
