解释计划中的串行到并行

Question

我正在尝试改进查询，而我对解释计划只有模糊的理解。此查询具有非常大的连接和许多表。我尝试过的一项改进是将所有连接分解为更小的子查询和组，以便它可以利用尽可能多地连接较小的数据集（仍然不完整它是一个非常大的查询）。 基础结构是

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.如果我可以保证所有连接语句都出现在分区/索引列上，是否有一些提示可以让运行器触发并行执行？

Answer 1

1. 从串口走向并行可能是一个浪费的机会。有些地方连续运行比并行运行更好。但是，如果查询的一部分已经并行运行，那么并行运行整个查询通常是有意义的。如果查询的任何部分并行运行，则查询已经产生并行性的各种“成本” - 复杂性，增加的资源等。并行运行它可能不会有什么坏处。当你考虑Amdahl's law时，担心任何串行代码都很重要。
2. 语句级别的提示使整个事物的并行化变得微不足道。使整个语句并行运行可能是微不足道的。使用statement-level parallel hint而不是对象级提示。写一个像select /*+ parallel(8) */ ...而不是select /*+ parallel(a) parallel_index(b) */ ...的查询。语句级提示更容易编写，在别名更改时不太容易被“忽略”，并且适用于索引扫描和表扫描。

在侧节点上，将查询分解为多个内联视图可能不会产生任何性能差异。 Oracle具有谓词推送和视图合并等优化功能，可以消除轻微的语法更改。但是，将大型查询分成块通常会在逻辑上理解查询的能力方面产生巨大差异。与少量大型查询相比，大量小型查询在理论上更容易理解。 （例如，将6连接查询与两个3连接查询进行比较 - 6！> 3！+ 3！。）将查询分解为小的，可理解的部分;但不要指望它能提高性能。