Oracle:在SELECT列表中不使用带有子查询的并行执行有什么逻辑原因吗？

Question

Oracle在SELECT列表中不使用标量子查询的并行执行有什么逻辑原因吗？为什么它不应该用它们？

只有满足以下条件，SELECT语句才能并行化：

• 查询包括并行提示规范(并行或PARALLEL_INDEX)，或者查询中引用的模式对象具有与它们关联的并行声明。
• 查询中指定的至少一个表需要下列之一：

- A full table scan
- An index range scan spanning multiple partitions

​

• 选择列表中没有标量子查询。

Answer 1

http://docs.oracle.com/cd/E11882_01/server.112/e25523/parallel003.htm#BEIJBCCD 中的每一项都是错误的。

(至少对Oracle11gR2和probably10g也是如此。对于一些过时版本的Oracle，列表可能是准确的。)

我建议尽可能使用正式的Oracle文档，但是并行执行章节并不十分准确。

而且，即使手册没有错，它也经常误导人，因为并行执行非常复杂。如果您查看所有文档，您会发现大约有30个不同的变量决定了并行性的程度。如果你曾经看到一个简短的项目清单，你应该非常怀疑。这些清单通常只是在非常具体的情况下要考虑的最相关的项目。

示例：

SQL> --Create a table without any parallel settings
SQL> create table parallel_test(a number primary key, b number);

Table created.

SQL> --Create some test data
SQL> insert into parallel_test
  2  select level, level from dual connect by level <= 100000;

100000 rows created.

SQL> commit;

Commit complete.

SQL> --Force the session to run the query in parallel
SQL> alter session force parallel query;

Session altered.
SQL> --Generate explain plan
SQL> explain plan for
  2  select a
  3     ,(
  4             select a
  5             from parallel_test parallel_test2
  6             where parallel_test2.a = parallel_test.a
  7     )
  8  from parallel_test;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------
Plan hash value: 3823224058

---------------------------------------------------------------------------------------------------------------------
| Id  | Operation               | Name         | Rows  | Bytes | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
---------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT        |              |   116K|  1477K|     9   (0)| 00:00:01 |        |      |            |
|*  1 |  INDEX UNIQUE SCAN      | SYS_C0028894 |     1 |    13 |     1   (0)| 00:00:01 |        |      |            |
|   2 |  PX COORDINATOR         |              |       |       |            |          |        |      |            |
|   3 |   PX SEND QC (RANDOM)   | :TQ10000     |   116K|  1477K|     9   (0)| 00:00:01 |  Q1,00 | P->S | QC (RAND)  |
|   4 |    PX BLOCK ITERATOR    |              |   116K|  1477K|     9   (0)| 00:00:01 |  Q1,00 | PCWC |            |
|   5 |     INDEX FAST FULL SCAN| SYS_C0028894 |   116K|  1477K|     9   (0)| 00:00:01 |  Q1,00 | PCWP |            |
---------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("PARALLEL_TEST2"."A"=:B1)

Note
-----
   - dynamic sampling used for this statement (level=2)

21 rows selected.

SQL>

没有并行提示，没有并行对象，没有完整的表扫描，没有跨越多个分区的索引范围扫描，还有一个标量子查询。

没有一个条件满足，但是查询仍然使用并行性。(我还验证了v$px_process，以确保查询确实使用并行性，而不仅仅是解释计划失败。)

这意味着其他问题的答案是错误的。

我不清楚在这种情况下到底发生了什么，但我认为这与FAST DUAL优化有关。在某些情况下，DUAL不被用作表，因此没有什么可并行化的。这可能是一个"bug"，但是如果您使用的是DUAL，那么您实际上并不需要并行性。(虽然我假设您在演示时使用了DUAL，但真正的查询要复杂得多。如果是这样的话，您可能需要用一个更实际的例子更新查询。)