如何讓Oracle產生預期的執行計劃（三）

在測試執行計劃、SQL最佳化、對比不同執行計劃的效率時，讓Oracle產生預期的執行計劃還是很有意義的。

前兩天在PUB上看到一個帖子，問為什麼一個查詢沒有產生INDEX_JOIN執行計劃。http://www.itpub.net/showthread.php?s=&threadid=829318

這裡就以INDEX_JOIN為例，簡單描述一下如何影響Oracle的執行計劃的產生。

介紹透過修改表中資料來產生預期的執行計劃。

如何讓Oracle產生預期的執行計劃（一）：http://yangtingkun.itpub.net/post/468/357542

如何讓Oracle產生預期的執行計劃（二）: http://yangtingkun.itpub.net/post/468/364939

上兩篇文章分別介紹了手工設定統計資訊和修改表結構來達到預期的執行計劃。這篇文章介紹透過修改表中的資料的方法，使得Oracle得到預期的執行計劃。

首先還是重建測試表：

SQL> DROP TABLE EMPLOYEES;

表已丟棄。

SQL> CREATE TABLE EMPLOYEES AS SELECT * FROM HR.EMPLOYEES;

表已建立。

SQL> ALTER TABLE EMPLOYEES ADD CONSTRAINT PK_EMPLOYEES PRIMARY KEY (EMPLOYEE_ID);

表已更改。

SQL> CREATE INDEX IND_EMP_SALARY ON EMPLOYEES (SALARY);

索引已建立。

SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(USER, 'EMPLOYEES', CASCADE => TRUE)

PL/SQL 過程已成功完成。

SQL> SET AUTOT TRACE
SQL> SELECT EMPLOYEE_ID, SALARY
2 FROM EMPLOYEES
3 WHERE SALARY > 2000;

已選擇107行。

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=107 Bytes=856)
1 0 TABLE ACCESS (FULL) OF 'EMPLOYEES' (Cost=2 Card=107 Bytes=856)

Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
12 consistent gets
0 physical reads
0 redo size
2273 bytes sent via SQL*Net to client
580 bytes received via SQL*Net from client
9 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
107 rows processed

雖然使用不同的方法，但是思路仍然是一樣的：使得表訪問的代價增加。如果在不修改表結構，不人為設定統計資訊的前提下，僅透過對資料進行修改，來提高表的訪問代價，方法只能是透過構造行遷移。

下面先產生測試表，然後用盡量短的資訊裝載表，最後透過UPDATE將表的長度增加，認為的構造大量的行遷移，從而提高表的訪問代價。

SQL> DELETE EMPLOYEES;

已刪除107行。

SQL> INSERT INTO EMPLOYEES
2 SELECT A.EMPLOYEE_ID*1000 + B.EMPLOYEE_ID,
3 NULL, ' ', ' ', NULL, A.HIRE_DATE, ' ',
4 A.SALARY, NULL, NULL, NULL
5 FROM HR.EMPLOYEES A, HR.EMPLOYEES B;

已建立11449行。

SQL> UPDATE EMPLOYEES
2 SET FIRST_NAME = LPAD('1', 20, '1'), LAST_NAME = LPAD('1', 25, '1'), EMAIL = LPAD('1', 25, '1'),
3 PHONE_NUMBER = LPAD('1', 20, '1'), JOB_ID = LPAD('1', 10, '1'), COMMISSION_PCT = 0.99,
4 MANAGER_ID = 999999, DEPARTMENT_ID = 9999
5 ;

已更新11449行。

SQL> COMMIT;

提交完成。

下面重新收集統計資訊：

SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(USER, 'EMPLOYEES')

PL/SQL 過程已成功完成。

SQL> SET AUTOT TRACE
SQL> SELECT EMPLOYEE_ID, SALARY
2 FROM EMPLOYEES
3 WHERE SALARY > 2000;

已選擇11449行。

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=12 Card=11449 Bytes=103041)
1 0 VIEW OF 'index$_join$_001' (Cost=12 Card=11449 Bytes=103041)
2 1 HASH JOIN
3 2 INDEX (RANGE SCAN) OF 'IND_EMP_SALARY' (NON-UNIQUE) (Cost=39 Card=11449 Bytes=103041)
4 2 INDEX (FAST FULL SCAN) OF 'PK_EMPLOYEES' (UNIQUE) (Cost=39 Card=11449 Bytes=103041)

Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
854 consistent gets
0 physical reads
2088 redo size
207404 bytes sent via SQL*Net to client
8896 bytes received via SQL*Net from client
765 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
11449 rows processed

透過對錶中資料進行修改，使得Oracle根據預期產生了INDEX_JOIN執行計劃。