我正在尝试改进查询,而我对解释计划只有模糊的理解。此查询具有非常大的连接和许多表。我尝试过的一项改进是将所有连接分解为更小的子查询和组,以便它可以利用尽可能多地连接较小的数据集(仍然不完整它是一个非常大的查询)。 基础结构是
select a.attr1, a..attr2, b.attr1, b.attr2, c.attr1, c.attr2, c.attr3 ...
from (select a1.attr1, a2.attr2 from tablea1 a1 join tablea2 a2 on a1.attr1 = a2.attr1) a
left outer join (select b1.attr1, b2.attr2 from tableb1 b1 join tableb2 b2 on b1.attr1 = b2.attr1)
left outer join (select c1.attr1, c2.attr2, c3.attr3 from tablec1 c1 join tablec2 c2 on c1.attr1 = c2.attr1 join tablec3 c3 on c1.attr1 = c3.attr1) c
....
当我尝试解释计划时,我注意到某些步骤,例如加入从串行到并行执行的a到c的结果。
我从中理解
不希望从并行到串行的http://www.oracle.com/technetwork/articles/database-performance/geist-parallel-execution-1-1872400.html。但是我没有看到谷歌提供的关于如何并行处理每个步骤的文档(在这种情况下是C组中的表格)。
1.从串口走向平行是想要还是坏?
2.如果我可以保证所有连接语句都出现在分区/索引列上,是否有一些提示可以让运行器触发并行执行?
答案 0 :(得分:2)
select /*+ parallel(8) */ ...
而不是select /*+ parallel(a) parallel_index(b) */ ...
的查询。语句级提示更容易编写,在别名更改时不太容易被“忽略”,并且适用于索引扫描和表扫描。在侧节点上,将查询分解为多个内联视图可能不会产生任何性能差异。 Oracle具有谓词推送和视图合并等优化功能,可以消除轻微的语法更改。但是,将大型查询分成块通常会在逻辑上理解查询的能力方面产生巨大差异。与少量大型查询相比,大量小型查询在理论上更容易理解。 (例如,将6连接查询与两个3连接查询进行比较 - 6!> 3!+ 3!。)将查询分解为小的,可理解的部分;但不要指望它能提高性能。