Oracle左连接视图性能

Question

我有两张桌子，它们不是大桌子。我已经根据这个表创建了一个视图

select 
  tab_a.id as id, 
  tab_a.name as name 
from tableA as tab_a

UNION ALL

select 
  tab_b.id as id, 
  tab_b.name as name 
from tableB as tab_b

毕竟，我有第三个表，让我们把它称为带字段的tableMain：

tableMain.id，tableMain.status，tableMain.viewId

viewId存在于视图中。

最后选择如下所示

SELECT tableMain.id
  FROM tableMain
  LEFT OUTER JOIN VIEW ON tableMain.viewId=view.id

在视野中加入是非常缓慢的。

如果我直接加入tableA或tableB，但在使用视图时却不是这样，那就太快了。

如果在select中使用view.name，可能会很快。

SELECT tableMain.id, VIEW.name
  FROM tableMain
  LEFT OUTER JOIN VIEW ON tableMain.viewId=view.id

如果我在select中使用视图字段，则不确定为什么视图联接工作得很快，

以及如何使视图在没有它的情况下快速连接。

张贴计划：

好计划(在选择中使用VIEW.name )

SELECT tableMain.id, VIEW.name
  FROM tableMain
  LEFT OUTER JOIN VIEW ON tableMain.viewId=view.id



| Id  | Operation            | Name           | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT     |                |   220K|   440M|    50   (4)| 00:00:01 |
|*  1 |  HASH JOIN OUTER     |                |   220K|   440M|    50   (4)| 00:00:01 |
|   2 |   TABLE ACCESS FULL  | **tableMain**  | 19796 |  1527K|    42   (0)| 00:00:01 |
|   3 |   VIEW               | ***VIEW***     |  1115 |  2194K|     6   (0)| 00:00:01 |
|   4 |    UNION-ALL         |                |       |       |            |          |
|   5 |     TABLE ACCESS FULL| **tableA**     |   818 |  1609K|     3   (0)| 00:00:01 |
|*  6 |     TABLE ACCESS FULL| **tableB**     |   297 |  5346 |     3   (0)| 00:00:01 |

坏计划(选择中没有view.name )

SELECT tableMain.id
  FROM tableMain
  LEFT OUTER JOIN VIEW ON tableMain.viewId=view.id

| Id  | Operation                     | Name            | Rows  | Bytes | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
|   0 | SELECT STATEMENT              |                 |   220K|    19M|    51   (6)| 00:00:01 |        |      |            |
|   1 |  PX COORDINATOR               |                 |       |       |            |          |        |      |            |
|   2 |   PX SEND QC (RANDOM)         | :TQ10003        |   220K|    19M|    51   (6)| 00:00:01 |  Q1,03 | P->S | QC (RAND)  |
|*  3 |    HASH JOIN RIGHT OUTER      |                 |   220K|    19M|    51   (6)| 00:00:01 |  Q1,03 | PCWP |            |
|   4 |     PX RECEIVE                |                 |  1115 | 14495 |     6   (0)| 00:00:01 |  Q1,03 | PCWP |            |
|   5 |      PX SEND HASH             | :TQ10002        |  1115 | 14495 |     6   (0)| 00:00:01 |  Q1,02 | P->P | HASH       |
|   6 |       BUFFER SORT             |                 |   220K|    19M|            |          |  Q1,02 | PCWP |            |
|   7 |        VIEW                   | ***VIEW***      |  1115 | 14495 |     6   (0)| 00:00:01 |  Q1,02 | PCWP |            |
|   8 |         UNION-ALL             |                 |       |       |            |          |  Q1,02 | PCWP |            |
|   9 |          PX BLOCK ITERATOR    |                 |   818 | 10634 |     3   (0)| 00:00:01 |  Q1,02 | PCWC |            |
|  10 |           INDEX FAST FULL SCAN| ***tableA_PK*** |   818 | 10634 |     3   (0)| 00:00:01 |  Q1,02 | PCWP |            |
|  11 |          BUFFER SORT          |                 |       |       |            |          |  Q1,02 | PCWC |            |
|  12 |           PX RECEIVE          |                 |   297 |  2079 |     3   (0)| 00:00:01 |  Q1,02 | PCWP |            |
|  13 |            PX SEND ROUND-ROBIN| :TQ10000        |   297 |  2079 |     3   (0)| 00:00:01 |        | S->P | RND-ROBIN  |
|* 14 |             TABLE ACCESS FULL | **tableB**      |   297 |  2079 |     3   (0)| 00:00:01 |        |      |            |
|  15 |     BUFFER SORT               |                 |       |       |            |          |  Q1,03 | PCWC |            |
|  16 |      PX RECEIVE               |                 | 19796 |  1527K|    42   (0)| 00:00:01 |  Q1,03 | PCWP |            |
|  17 |       PX SEND HASH            | :TQ10001        | 19796 |  1527K|    42   (0)| 00:00:01 |        | S->P | HASH       |
|  18 |        TABLE ACCESS FULL      | **tableMain**   | 19796 |  1527K|    42   (0)| 00:00:01 |        |      |            |

为什么有这么大的差别？

Answer 1

有东西在强迫并行。这个视图有什么提示吗？此查询是否存在某种类型的计划管理？例如，是否只有在糟糕的查询上有大纲、SQL计划管理或配置文件设置？您可以通过添加解释计划的Note部分来找出答案。如果我是对的，只有一个执行计划会出现这样的情况：

Note
-----
   - SQL plan baseline "SQL_PLAN_01yu884fpund494ecae5c" used FOR this statement

此外，它将有助于定义“非常慢”。如果好的查询在0.01秒内运行，而坏的查询在2秒内运行，那么差异可能都是由于并行性的开销。但是，如果查询是针对具有更大数据的环境进行调优的，那么您可能希望保留这个糟糕的计划--它可能在生产中运行得更好。