Oracle LEFT JOIN 查看性能

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存在加入view

最终选择的样子

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

在 VIEW 上加入 非常慢。

如果我直接加入 tableA 或 tableB 会很快，但在使用视图时不会。

如果我在选择中使用 view.name 会更快

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

如果我在选择中使用 VIEW 字段，不知道为什么 VIEW JOIN 工作得很快，

以及如何在没有它的情况下快速进行 VIEW JOIN。

发布计划：

好计划（在 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 秒内运行，差异可能都是因为 并行性。但是，如果查询是针对具有更大数据的环境进行调整的，那么您可能仍然希望保留这个糟糕的计划 - 它可能在生产中运行得更好。