Oracle如何实现针对基表自定义视图的SQL查询执行逻辑

核心问题结论 #

• 正常情况下，Oracle不会先执行视图定义对应的query1生成独立临时表，再在临时表上运行你写的query2。
• 优化器默认会优先把视图的定义逻辑（query1）和你的外层查询（query2）做语义对齐整合，拼成单条直接访问底层基表的复合查询，基于全局的表统计信息生成最优执行计划。
• 你提到的“query2在基表上具备高选择性”的场景，恰恰是优化器最倾向于做逻辑合并的场景：合并后query2的过滤条件可以直接下推到基表，命中对应索引快速缩小扫描范围，执行效率远高于先全量跑一遍query1再过滤临时结果的模式。

例外触发场景 #

只有当视图的逻辑不满足合并要求时，Oracle才会先执行query1生成临时结果集，再运行query2，常见触发情况包括：

• 视图定义本身带有无法下推的特殊语法：比如DISTINCT、聚合计算、GROUP BY、ROWNUM、层级查询、窗口函数这类需要先完成全量数据计算才能输出合法结果的逻辑，无法直接把外层过滤条件下推到基表。
• 视图定义中显式添加了NO_MERGE优化提示，强制要求优化器不对视图做逻辑合并。
• 优化器基于成本计算判定，先物化视图结果的执行总成本，低于做逻辑合并后的查询成本（比如视图本身返回的结果集极小，外层query2的过滤条件选择度极低）。

快速验证执行逻辑的方法 #

你可以通过执行执行计划查看实际的执行路径：

• 先运行EXPLAIN PLAN FOR <你要执行的query2完整语句>，再查询生成的执行计划详情
• 如果计划中直接出现了底层基表的扫描节点（比如索引范围扫描、全表扫描），没有独立的VIEW节点包裹完整的query1逻辑，就说明已经做了逻辑合并，是复合查询在执行
• 如果计划中出现独立的VIEW节点，且节点下包裹了完整的query1执行逻辑，才说明是先跑query1生成临时结果、再运行query2的模式。

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