执行计划顺序不符合一般规则

? 在Oracle performance tuning guide中，对执行计划顺序的描述是最右最上最先执行，然后父步骤执行，也就是最右边的步骤最先执行，如果同等级，那么最上边的最先执行，然后执行其父步骤（文档原文：The execution order in EXPLAIN PLAN output begins with

? 在Oracle performance tuning guide中，对执行计划顺序的描述是最右最上最先执行，然后父步骤执行，也就是最右边的步骤最先执行，如果同等级，那么最上边的最先执行，然后执行其父步骤（文档原文：The execution order in EXPLAIN PLAN output begins with the line that is the?furthest indented to the right. The next step is the parent of that line. If two lines?are indented equally, then the top line is normally executed first）。

? ? ? 在实际应用中，这个规则不是完全正确的。ORACLE的SQL内部步骤的执行顺序与其计划中的展现，会有一定的差别，如果不仔细分析，而且一味相信文档，那么可能会感觉很迷惑。比如在标量子查询中(scalary subquery)，执行计划的显示会非常让人困惑，如：

SQL> select * from a;
? ? ? ? ID NAME
———- ———————————-
? ? ? ? ?1 a
? ? ? ? ?2 b
? ? ? ? ?3 c
3 rows selected.

SQL> select * from b;
? ? ? ? ID NAME
———- ———————————-
? ? ? ? ?1 x1
? ? ? ? ?2 x2
2 rows selected.

SQL> SELECT a.ID,a.NAME,(SELECT b.ID FROM b WHERE a.ID=b.ID)?bid FROM a;

执行计划
———————————————————-
Plan hash value: 2657529235
————————————————————————–
| Id ?| Operation ? ? ? ? | Name | Rows ?| Bytes | Cost (%CPU)| Time ? ? |
————————————————————————–
| ? 0 | SELECT STATEMENT ?| ? ? ?| ? ? 3 | ? ?60 | ? ? 3 ? (0)| 00:00:01 |
|* ?1 | ?TABLE ACCESS FULL| B ? ?| ? ? 1 | ? ?13 | ? ? 3 ? (0)| 00:00:01 |
| ? 2 | ?TABLE ACCESS FULL| A ? ?| ? ? 3 | ? ?60 | ? ? 3 ? (0)| 00:00:01 |
————————————————————————–
Predicate Information (identified by operation id):
—————————————————
? ?1 – filter(“B”.”ID”=:B1)

? ? ??如果按照文档的的分析，显然ID=2的与ID=1的是同等级的，ID=1的在ID=2的上面，那么最后执行计划的顺序应该是1—->2—–>0，但是分析下，显然不是这样的顺序，肯定是必须获得a.id之后，才能用a.id去查找B。通过谓词中的”B”.”ID”=:B1可以看出来，:B1,类似于绑定变量，这里就2张表，而且根据SQL查询，肯定来源于A.ID。所以对于标量子查询的计划，应该是2—->1—–>0，而且2与1的操作是类似于NESTED LOOPS(与其不同的是，标量子查询的驱动表是inner table)的操作，每1个A的行，都会执行一次B，当然，ORACLE内部肯定是有优化的，这种优化就是会缓存已经匹配的A.ID值，遇到相同的，不会重复扫描B。可以通过DBMS_XPLAN.DISPLAY_CURSOR详细看看如何执行的：

SQL> @display_cursor
SQL_ID ?caq6tcx266xnq, child number 1
————————————-
SELECT a.ID,a.NAME,(SELECT b.ID FROM b WHERE a.ID=b.ID) bid FROM a

Plan hash value: 2657529235
————————————————————————————
| Id ?| Operation ? ? ? ? | Name | Starts | E-Rows | A-Rows | ? A-Time ? | Buffers |
————————————————————————————
| ? 0 | SELECT STATEMENT ?| ? ? ?| ? ? ?1 | ? ? ? ?| ? ? ?3 |00:00:00.01 | ? ? ? 8 |
|* ?1 | ?TABLE ACCESS FULL| B ? ?| ? ???3?| ? ? ?1 | ? ? ?2 |00:00:00.01 | ? ? ?21 |
| ? 2 | ?TABLE ACCESS FULL| A ? ?| ? ? ?1 | ? ? ?3 | ? ???3?|00:00:00.01 | ? ? ? 8 |
————————————————————————————

Predicate Information (identified by operation id):
—————————————————
? ?1 – filter(“B”.”ID”=:B1)

? ? ??其中A共3行，访问B 3次，返回B 2行，因为有一行不匹配，由A的行驱动访问B。因为这里A.ID无重复值，下面插入一行id=1的，因为id=1已经在A表中存在，因此，标量子查询有缓存，所以对B的扫描还是3次，而不是4次，如下：

SQL> INSERT INTO a VALUES(1,’d');
1 row created.

SQL> COMMIT;
Commit complete.

SQL>??@display_cursor
SQL_ID ?caq6tcx266xnq, child number 0
————————————-
SELECT a.ID,a.NAME,(SELECT b.ID FROM b WHERE a.ID=b.ID) bid FROM a

Plan hash value: 2657529235

————————————————————————————
| Id ?| Operation ? ? ? ? | Name | Starts | E-Rows | A-Rows | ? A-Time ? | Buffers |
————————————————————————————
| ? 0 | SELECT STATEMENT ?| ? ? ?| ? ? ?1 | ? ? ? ?| ? ? ?4 |00:00:00.01 | ? ? ? 8 |
|* ?1 | ?TABLE ACCESS FULL| B ? ?| ? ???3?| ? ? ?1 | ? ? ?2?|00:00:00.01 | ? ? ?21 |
| ? 2 | ?TABLE ACCESS FULL| A ? ?| ? ? ?1 | ? ? ?4 | ? ???4?|00:00:00.01 | ? ? ? 8 |
————————————————————————————

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

? ?1 – filter(“B”.”ID”=:B1)

? ? ?从计划中可以看到，虽然A是4行，但是因为DISTINCT A.ID是3行，所以还是扫描B 3次，其中ID=1的访问一次即缓存结果，通过A-ROWS可以看到B还是返回2行，而不是3行。所以不要看到标量子查询就认为效率不行，标量子查询和FILTER类似，如果能够对标量子查询走索引扫描，甚至UNIQUE INDEX SCAN，如果主表查询的行重复值特别多，效率还是很高的，标量子查询在一定程度上，消除了JOIN，经常在查询这种对应某表的行，需要匹配另一表的某个列值，比JOIN效率高（当然，既然类似于NESTED LOOPS了，结果集肯定不会很大，不然效率会差，这个tom的高效设计上有详细的讲解）。
? ?
? ? 本文主要就是讲解下，执行计划反应了SQL的执行顺序，但是如果通过执行计划准确知道SQL中的执行顺序，并不是只要了解文档中说的规则就可以了，在实际应用中，可能会碰到这样那样的问题，文档当然很少有错误，但是文档大多说的都是普遍的规则，SO，在学习过程中，对不理解的问题，要随时质疑，并论证之。

原文地址：执行计划顺序不符合一般规则, 感谢原作者分享。