執行計劃順序不符合一般規則

來源：懂視網責編：小采時間：2020-11-09 13:06:22

執行計劃順序不符合一般規則

執行計劃順序不符合一般規則: 在Oracle performance tuning guide中，對執行計劃順序的描述是最右最上最先執行，然后父步驟執行，也就是最右邊的步驟最先執行，如果同等級，那么最上邊的最先執行，然后執行其父步驟（文檔原文：The execution order in EXPLAIN PL

推薦度：

點擊下載本文 文檔為doc格式

導讀執行計劃順序不符合一般規則: 在Oracle performance tuning guide中，對執行計劃順序的描述是最右最上最先執行，然后父步驟執行，也就是最右邊的步驟最先執行，如果同等級，那么最上邊的最先執行，然后執行其父步驟（文檔原文：The execution order in EXPLAIN PL

? 在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，在學習過程中，對不理解的問題，要隨時質疑，并論證之。

原文地址：執行計劃順序不符合一般規則, 感謝原作者分享。

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com

執行計劃順序不符合一般規則

推薦度：

點擊下載本文 文檔為doc格式

標簽：計劃規則不符合

熱門焦點

執行計劃順序不符合一般規則

執行計劃順序不符合一般規則

執行計劃順序不符合一般規則

最新推薦

猜你喜歡

熱門推薦