Oracle中Hint被忽略的幾種常見情形

時間  2020-03-30
標籤 oracle hint 忽略 幾種 常見 情形 欄目 Oracle 简体版
原文   原文鏈接

Hint能夠影響優化器對於執行計劃的選擇，但這種影響不是強制性的，優化器在某些狀況下可能會忽略目標SQL中的Hint。因爲各類緣由致使Hint被Oracle忽略後，Oracle並不會給出任何提示或者警告，更不會報錯，目標SQL依然能夠正常運行，這也符合Hint其實是一種特殊註釋的身份。註釋原本就是無關緊要的東西，不該該由於它的存在而而致使原先在沒有Hint時能夠正常執行的SQL由於加了Hint後而變得不能正常執行。sql

下面來看幾種Hint被Oracle忽略的常見情形。ide

1 使用的Hint有語法或者拼寫錯誤測試

一旦使用的Hint中有語法或者拼寫錯誤，Oracle就會忽略該Hint，看幾個示例SQL：優化

  1. select /*+ ind(emp pk_emp) */* from emp;this

  2. select /*+ index(emp pk_emp */* from emp;索引

  3. select /* + index(emp pk_emp) */* from emp;ci

  4. select */*+ index(emp pk_emp) */ from emp;hash

  5. select /*+ index(scott.emp pk_emp) */* from emp;it

  6. select /*+ index(emp pk_emp) */* from emp e;io

  7. select /*+ index(emp emp_pk) */* from emp;

  8. select /*+ full(t2) */ t1.ename,t1.deptno from emp t1 where t1.deptno in (select t2.deptno from detp t where t2.loc='CHICAGO');

實際上，上述8條SQL中的Hint都是無效的，它們都會被Oracle忽略。

1是由於關鍵字應該是"index"而不是"ind"

2是由於漏掉了一個右括號

3是由於Hint中第一個*和+之間出現了空格

4是由於Hint出現的位置不對，它應該出如今*前面

5是由於emp表前面帶上了SCHEME名稱

6是由於沒有emp表的別名

7是由於索引名稱寫錯了

8是由於Hint跨了Query Block。Hint生效的範圍公限於它自己所在的Query Block，若是將某個Hint生將範圍擴展到它所在的Query Block以外而又沒在該Hint中指定其生效的Query Block名稱的話，Oracle就會忽略該Hint。

2 使用的Hint無效

即便語法是正確的，但若是因爲某種緣由致使Oracle認爲這個Hint無效，則Oracle仍是會忽略該Hint。

看幾個實例

scott@TEST>set autotrace traceonly 
scott@TEST>select /*+ index(dept idx_dept_loc) */ deptno,dname from dept where loc='CHICAGO';


Execution Plan
----------------------------------------------------------
Plan hash value: 492093765

--------------------------------------------------------------------------------------------
| Id  | Operation		    | Name	   | Rows  | Bytes | Cost (%CPU)| Time	   |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT	    |		   |	10 |   300 |	 2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| DEPT	   |	10 |   300 |	 2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN	    | IDX_DEPT_LOC |	 4 |	   |	 1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------
......

從上面的輸出能夠看出，上面的SQL的執行計劃走的是對索引IDX_DEPT_LOC的索引範圍掃描，說明Hint生效了，可是若是把where條件替換爲與索引IDX_DEPT_LOC絕不相關的deptno=30，再來看執行狀況

scott@TEST>select /*+ index(dept idx_dept_loc) */ deptno,dname from dept where deptno=30;


Execution Plan
----------------------------------------------------------
Plan hash value: 2852011669

---------------------------------------------------------------------------------------
| Id  | Operation		    | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT	    |	      |     1 |    22 |     2	(0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| DEPT    |     1 |    22 |     2	(0)| 00:00:01 |
|*  2 |   INDEX UNIQUE SCAN	    | PK_DEPT |     1 |       |     1	(0)| 00:00:01 |
---------------------------------------------------------------------------------------
......

從上面的輸出能夠看出，執行計劃走的是對主鍵PK_DEPT的INDEX UNIQUE SCAN，面不是Hint裏的IDX_DEPT_LOC。這就說明Hint在這個SQL失效了。

即便不改where條件，若是把索引IDX_DEPT_LOC刪除，這個Hint也會失效：

scott@TEST>drop index idx_dept_loc;

Index dropped.

scott@TEST>select /*+ index(dept idx_dept_loc) */ deptno,dname from dept where loc='CHICAGO';


Execution Plan
----------------------------------------------------------
Plan hash value: 3383998547

--------------------------------------------------------------------------
| Id  | Operation	  | Name | Rows  | Bytes | Cost (%CPU)| Time	 |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |	 |    10 |   300 |    29   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| DEPT |    10 |   300 |    29   (0)| 00:00:01 |
--------------------------------------------------------------------------

從上面的執行計劃能夠看出走的是對錶DEPT的TABLE ACCESS FULL，Hint也是失效的。

再來看一個使用組合Hint的例子，先看以下SQL的執行計劃

scott@TEST>select /*+ full(dept) parallel(dept 2) */ deptno from dept;


Execution Plan
----------------------------------------------------------
Plan hash value: 587379989

--------------------------------------------------------------------------------------------------------------
| Id  | Operation	     | Name	| Rows	| Bytes | Cost (%CPU)| Time	|    TQ  |IN-OUT| PQ Distrib |
--------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |		|  1000 | 13000 |    16   (0)| 00:00:01 |	 |	|	     |
|   1 |  PX COORDINATOR      |		|	|	|	     |		|	 |	|	     |
|   2 |   PX SEND QC (RANDOM)| :TQ10000 |  1000 | 13000 |    16   (0)| 00:00:01 |  Q1,00 | P->S | QC (RAND)  |
|   3 |    PX BLOCK ITERATOR |		|  1000 | 13000 |    16   (0)| 00:00:01 |  Q1,00 | PCWC |	     |
|   4 |     TABLE ACCESS FULL| DEPT	|  1000 | 13000 |    16   (0)| 00:00:01 |  Q1,00 | PCWP |	     |
--------------------------------------------------------------------------------------------------------------
......

從上面輸出內容能夠看出，如今是對錶DEPT作的並行全表掃描，說明組合Hint中的兩個都生效了，這個Hint的含義是既要全表掃描又要並行訪問表DEPT，二者不矛盾，由於全表掃描能夠並行執行。再看以下的SQL：

scott@TEST>select /*+ index(dept pk_dept) parallel(dept 2) */ deptno from dept;

4 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 2913917002

----------------------------------------------------------------------------
| Id  | Operation	 | Name    | Rows  | Bytes | Cost (%CPU)| Time	   |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT |	   |  1000 | 13000 |	26   (0)| 00:00:01 |
|   1 |  INDEX FULL SCAN | PK_DEPT |  1000 | 13000 |	26   (0)| 00:00:01 |
----------------------------------------------------------------------------
......

如今SQL走的是對索引PK_DEPT的索引全掃描，可是串行的，說明Hint中的parallel(dept 2)失效了，由於表DEPT上的主鍵索引PK_DEPT不是分區索引，而對於非分區索引而言，索引範圍掃描或索引全掃描並不能並行執行，因此上述組合Hint中忽略了parallel(dept 2)。

再看一個HASH JOIN的例子：

下面的SQL中use_hash的Hint是生效的：

scott@TEST>select /*+ use_hash(t1) */ t1.empno,t1.empno,t2.loc from emp t1,dept t2 where t1.deptno=t2.deptno and t2.loc='CHICAGO';

6 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 615168685

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     5 |   185 |     7  (15)| 00:00:01 |
|*  1 |  HASH JOIN         |      |     5 |   185 |     7  (15)| 00:00:01 |
|*  2 |   TABLE ACCESS FULL| DEPT |     1 |    11 |     3   (0)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| EMP  |    14 |   364 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------
-

可是若是把SQL修改成以下則use_hash的Hint就會被忽略

scott@TEST>select /*+ use_hash(t1) */ t1.empno,t1.empno,t2.loc from emp t1,dept t2 where t1.deptno>t2.deptno and t2.loc='CHICAGO';

no rows selected

Execution Plan
----------------------------------------------------------
Plan hash value: 4192419542

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |    37 |     6   (0)| 00:00:01 |
|   1 |  NESTED LOOPS      |      |     1 |    37 |     6   (0)| 00:00:01 |
|*  2 |   TABLE ACCESS FULL| DEPT |     1 |    11 |     3   (0)| 00:00:01 |
|*  3 |   TABLE ACCESS FULL| EMP  |     1 |    26 |     3   (0)| 00:00:01 |
---------------------------------------------------------------------------

從上面的執行計劃中看出use_hash確實是被Oracle忽略了，這是由於哈希鏈接只適用於等值鏈接條件，不等值的鏈接條件對哈希鏈接而言是沒有意義的，因此上述Hint就被Oracle忽略了。

3 使用的Hint自相矛盾

若是使用的組合Hint是自相矛盾的，則這些自相矛盾的Hint都會被Oracle忽略。但Oracle只會將自相矛盾的Hint所有忽略掉，但若是使用的組合Hint中還有其餘有效的Hint，則這些有效Hint不受影響。

看一個使用自相矛盾Hint的實例，先執行單個Hint的SQL

scott@TEST>select /*+ index_ffs(dept pk_dept)*/ deptno from dept;

4 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 2578398298

--------------------------------------------------------------------------------
| Id  | Operation	     | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |	       |     4 |    12 |     2	 (0)| 00:00:01 |
|   1 |  INDEX FAST FULL SCAN| PK_DEPT |     4 |    12 |     2	 (0)| 00:00:01 |
--------------------------------------------------------------------------------
......
scott@TEST>select /*+ full(dept)*/ deptno from dept;

4 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 3383998547

--------------------------------------------------------------------------
| Id  | Operation	  | Name | Rows  | Bytes | Cost (%CPU)| Time	 |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |	 |     4 |    12 |     3   (0)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| DEPT |     4 |    12 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------

從上面的輸出能夠看出單獨使用上面的兩個Hint都能被Oracle生效，但若是這兩個Hint合併到一塊兒使用就不是那麼回事了：

scott@TEST>select /*+ index_ffs(dept pk_dept) full(dept)*/ deptno from dept;

4 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 2913917002

----------------------------------------------------------------------------
| Id  | Operation	 | Name    | Rows  | Bytes | Cost (%CPU)| Time	   |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT |	   |	 4 |	12 |	 1   (0)| 00:00:01 |
|   1 |  INDEX FULL SCAN | PK_DEPT |	 4 |	12 |	 1   (0)| 00:00:01 |
----------------------------------------------------------------------------

從上面的輸出能夠看出執行計劃沒有走Hint中指定的執行計劃，而是對主鍵索引PK_DEPT作的是INDEX FULL SCAN這說明Hint中的兩個都失效了。

再來看下面的例子：

scott@TEST>select /*+ index_ffs(dept pk_dept) full(dept) cardinality(dept 1000) */ deptno from dept;

4 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 2913917002

----------------------------------------------------------------------------
| Id  | Operation	 | Name    | Rows  | Bytes | Cost (%CPU)| Time	   |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT |	   |  1000 |  3000 |	 1   (0)| 00:00:01 |
|   1 |  INDEX FULL SCAN | PK_DEPT |  1000 |  3000 |	 1   (0)| 00:00:01 |
----------------------------------------------------------------------------

從上面的輸出能夠看出執行計劃走的仍然是對主鍵索引PK_DEPT作的是INDEX FULL SCAN，可是作INDEX FULL SCAN反回結果集的cardinality從原來的4變爲了1000，說明cardinality(dept 1000)生效了，也驗證了若是使用的組合Hint中還有其餘有效的Hint，則這些有效Hint不受影響。

4 使用的Hint受到了查詢轉換的干擾

有時候，查詢轉換也會致使相關的Hint失效，即Hint被Oracle忽略還多是由於受到了查詢轉換的干擾。

下面來看一個由於使用了查詢轉換而致使相關Hint被Oracle忽略掉的實例。

建立一個測試表jobs

scott@TEST>create table jobs as select empno,job from emp;

Table created.

構造一個SQL

select /*+ ordered cardinality(e 100) */
 e.ename, j.job, e.sal, v.avg_sal
  from emp e,
       jobs j,
       (select /*+ merge */
         e.deptno, avg(e.sal) avg_sal
          from emp e, dept d
         where d.loc = 'chicago'
           and d.deptno = e.deptno
         group by e.deptno) v
 where e.empno = j.empno
   and e.deptno = v.deptno
   and e.sal > v.avg_sal
 order by e.ename;

上面的SQL是兩個表(EMP和JOBS)和內嵌視圖V關聯的SQL，其中內嵌視圖V又是由表EMP和DEPT關聯後獲得的。在此SQL中使用了三個Hint，其中merge用於讓內嵌視圖V作視圖合併，ordered表示上述SQL在執行時表EMP、JOBS和內嵌視圖V的鏈接順序應該和它們在該SQL的SQL文本中出現的順序一致，即它們應該是按照從左至右的順序依次作錶鏈接。

若是上述三個Hint都生效的話，那目標SQL的執行計劃中應該不會出現關鍵字「VIEW」(表示作了視圖合併，體現了Merge Hint的做用)，表EMP、JOBS和內嵌視圖V的鏈接應該會變成表EMP、JOBS和內嵌視圖V所對應的基表EMP和DEPT的鏈接，且鏈接的前後順序應該是EMP->JOBS->內嵌視圖V所對應的基表EMP和DEPT(體現了Ordered Hint的做用)，外圍查詢中表EMP的掃描結果所對應的Cardinality的值應該是100(體現了Cardinality Hint的做用)。

如今看一下實際狀況，執行上面的SQL:

scott@TEST>select /*+ ordered cardinality(e 100) */
  2   e.ename, j.job, e.sal, v.avg_sal
  3    from emp e,
  4         jobs j,
  5         (select /*+ merge */
  6           e.deptno, avg(e.sal) avg_sal
  7            from emp e, dept d
  8           where d.loc = 'chicago'
  9             and d.deptno = e.deptno
 10           group by e.deptno) v
 11   where e.empno = j.empno
 12     and e.deptno = v.deptno
 13     and e.sal > v.avg_sal
 14   order by e.ename;

no rows selected


Execution Plan
----------------------------------------------------------
Plan hash value: 930847561

-------------------------------------------------------------------------------
| Id  | Operation              | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |      |   156 | 19656 |    15  (20)| 00:00:01 |
|*  1 |  FILTER                |      |       |       |            |          |
|   2 |   SORT GROUP BY        |      |   156 | 19656 |    15  (20)| 00:00:01 |
|*  3 |    HASH JOIN           |      |   156 | 19656 |    14  (15)| 00:00:01 |
|*  4 |     TABLE ACCESS FULL  | DEPT |     1 |    11 |     3   (0)| 00:00:01 |
|*  5 |     HASH JOIN          |      |   467 | 53705 |    10  (10)| 00:00:01 |
|   6 |      TABLE ACCESS FULL | EMP  |    14 |   364 |     3   (0)| 00:00:01 |
|*  7 |      HASH JOIN         |      |   100 |  8900 |     7  (15)| 00:00:01 |
|   8 |       TABLE ACCESS FULL| EMP  |   100 |  5800 |     3   (0)| 00:00:01 |
|   9 |       TABLE ACCESS FULL| JOBS |    14 |   434 |     3   (0)| 00:00:01 |
-------------------------------------------------------------------------------

從上面的執行計劃能夠看出，確實沒有出現關鍵字「VIEW」，表EMP的掃描結果所對應的Cardinality的值確實是100，但鏈接順序不是上面提到的順序，而是先選擇的表DEPT。這說明上述三個Hint中的Merge Hint和Cardinality Hint生效了，但Ordered Hint被Oracle忽略了。這是由於受到了查詢轉換的干擾(對內嵌視圖V作視圖合併是一種查詢轉換)。

爲了證實上述SQL的Ordered Hint被Oracle忽略是由於受到了查詢轉換的干擾，如今將內嵌視圖V中的merge替換爲no_merge(不讓內嵌視圖作視圖合併)，再次執行該SQL：

scott@TEST>select /*+ ordered cardinality(e 100) */
  2   e.ename, j.job, e.sal, v.avg_sal
  3    from emp e,
  4         jobs j,
  5         (select /*+ no_merge */
  6           e.deptno, avg(e.sal) avg_sal
  7            from emp e, dept d
  8           where d.loc = 'chicago'
  9             and d.deptno = e.deptno
 10           group by e.deptno) v
 11   where e.empno = j.empno
 12     and e.deptno = v.deptno
 13     and e.sal > v.avg_sal
 14   order by e.ename;

no rows selected


Execution Plan
----------------------------------------------------------
Plan hash value: 2898000699

--------------------------------------------------------------------------------------------
| Id  | Operation                        | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                 |         |     8 |   728 |    14  (22)| 00:00:01 |
|   1 |  SORT ORDER BY                   |         |     8 |   728 |    14  (22)| 00:00:01 |
|*  2 |   HASH JOIN                      |         |     8 |   728 |    13  (16)| 00:00:01 |
|*  3 |    HASH JOIN                     |         |   100 |  6500 |     7  (15)| 00:00:01 |
|   4 |     TABLE ACCESS FULL            | EMP     |   100 |  4600 |     3   (0)| 00:00:01 |
|   5 |     TABLE ACCESS FULL            | JOBS    |    14 |   266 |     3   (0)| 00:00:01 |
|   6 |    VIEW                          |         |     5 |   130 |     6  (17)| 00:00:01 |
|   7 |     HASH GROUP BY                |         |     5 |   185 |     6  (17)| 00:00:01 |
|   8 |      MERGE JOIN                  |         |     5 |   185 |     6  (17)| 00:00:01 |
|*  9 |       TABLE ACCESS BY INDEX ROWID| DEPT    |     1 |    11 |     2   (0)| 00:00:01 |
|  10 |        INDEX FULL SCAN           | PK_DEPT |     4 |       |     1   (0)| 00:00:01 |
|* 11 |       SORT JOIN                  |         |    14 |   364 |     4  (25)| 00:00:01 |
|  12 |        TABLE ACCESS FULL         | EMP     |    14 |   364 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------

從上面的執行計劃中能夠看出，出現了「VIEW」關鍵字，說明沒有作視圖合併，表EMP對就的Cardinality爲100，鏈接順序與前面預想的一致，這說明在禁掉了查詢轉換後以前被忽略的Ordered Hint又生效了。

5 使用的Hint受到了保留關鍵字的干擾


Oracle在解析Hint時，是按照從左到右的順序進行的，若是遇到的詞是Oracle的保留關鍵字，則Oracle將忽略這個詞以及以後的全部詞；若是遇到詞既不是關鍵字也不是Hint，就忽略該詞；若是遇到的詞是有效的Hint，那麼Oracle就會保留該Hing。

正是因爲上述Oracle解析Hint的原則，保留關鍵字也可能致使相關的Hint失效。

Oracle的保留關鍵字能夠從視圖V$RESERVED_WORDS中查到，從下面的查詢結果能夠看到','、'COMMENT'、'IS'都是保留關鍵字，但「THIS」不是

scott@TEST>select keyword,length from v$reserved_words where keyword in (',','THIS','IS','COMMENT');

KEYWORD        LENGTH
---------- ----------
,                   1
COMMENT             7
IS                  2

下面來看一個保留關鍵字致使Hint失效的實例，執行下面的SQL

scott@TEST>select t1.empno,t1.empno,t2.loc from emp t1,dept t2 where t1.deptno=t2.deptno;

14 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 844388907

----------------------------------------------------------------------------------------
| Id  | Operation                    | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |         |    14 |   518 |     6  (17)| 00:00:01 |
|   1 |  MERGE JOIN                  |         |    14 |   518 |     6  (17)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| DEPT    |     4 |    44 |     2   (0)| 00:00:01 |
|   3 |    INDEX FULL SCAN           | PK_DEPT |     4 |       |     1   (0)| 00:00:01 |
|*  4 |   SORT JOIN                  |         |    14 |   364 |     4  (25)| 00:00:01 |
|   5 |    TABLE ACCESS FULL         | EMP     |    14 |   364 |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------

從執行計劃上看走的是MERGE SORT JOIN，對SQL加入以下Hint並執行：

scott@TEST>select /*+ use_hash(t1) index(t2 pk_dept) */ t1.empno,t1.empno,t2.loc from emp t1,dept t2 where t1.deptno=t2.deptno;

14 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 2622742753

----------------------------------------------------------------------------------------
| Id  | Operation                    | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |         |    14 |   518 |     6  (17)| 00:00:01 |
|*  1 |  HASH JOIN                   |         |    14 |   518 |     6  (17)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| DEPT    |     4 |    44 |     2   (0)| 00:00:01 |
|   3 |    INDEX FULL SCAN           | PK_DEPT |     4 |       |     1   (0)| 00:00:01 |
|   4 |   TABLE ACCESS FULL          | EMP     |    14 |   364 |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------

從上面的執行計劃中能夠看出Hint中的兩個都生效了，emp作HASH JOIN的被驅動表，對DEPT表作使用索引PK_DEPT。如今對Hint加入','，查看執行狀況:

scott@TEST>select /*+ use_hash(t1) , index(t2 pk_dept) */ t1.empno,t1.empno,t2.loc from emp t1,dept t2 where t1.deptno=t2.deptno;

14 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 615168685

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |    14 |   518 |     7  (15)| 00:00:01 |
|*  1 |  HASH JOIN         |      |    14 |   518 |     7  (15)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| DEPT |     4 |    44 |     3   (0)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| EMP  |    14 |   364 |     3   (0)| 00:00:01 |
---------------------------------------------------------------------------

從執行計劃中能夠看出，仍然走的是HASH JOIN可是index(t2 pk_dept)失效了。由於','是Oracle的保留關鍵字，因此','後面的index(t2 pk_dept)失效了，再修改Hint以下並執行SQL：

scott@TEST>select /*+ comment use_hash(t1) index(t2 pk_dept) */ t1.empno,t1.empno,t2.loc from emp t1,dept t2 where t1.deptno=t2.deptno;

14 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 844388907

----------------------------------------------------------------------------------------
| Id  | Operation                    | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |         |    14 |   518 |     6  (17)| 00:00:01 |
|   1 |  MERGE JOIN                  |         |    14 |   518 |     6  (17)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| DEPT    |     4 |    44 |     2   (0)| 00:00:01 |
|   3 |    INDEX FULL SCAN           | PK_DEPT |     4 |       |     1   (0)| 00:00:01 |
|*  4 |   SORT JOIN                  |         |    14 |   364 |     4  (25)| 00:00:01 |
|   5 |    TABLE ACCESS FULL         | EMP     |    14 |   364 |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------

從執行計劃中看出，如今走的是跟一開始的執行計劃同樣，說明Hint中的兩個都失效了，由於這兩個都在Oracle保留關鍵字comment後面。再修改Hint以下再次執行SQL:

scott@TEST>select /*+ this use_hash(t1) index(t2 pk_dept) */ t1.empno,t1.empno,t2.loc from emp t1,dept t2 where t1.deptno=t2.deptno;

14 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 2622742753

----------------------------------------------------------------------------------------
| Id  | Operation                    | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |         |    14 |   518 |     6  (17)| 00:00:01 |
|*  1 |  HASH JOIN                   |         |    14 |   518 |     6  (17)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| DEPT    |     4 |    44 |     2   (0)| 00:00:01 |
|   3 |    INDEX FULL SCAN           | PK_DEPT |     4 |       |     1   (0)| 00:00:01 |
|   4 |   TABLE ACCESS FULL          | EMP     |    14 |   364 |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------

如今執行計劃又走出了Hint指定的樣子，說明兩個都生效了，這是由於this不是Oracle保留關鍵字。

以上介紹了5種Hint被Oracle忽略的狀況，在實例使用過程當中必定要注意使用方法，使用正確有效的Hint來提高SQL執行效率，避免Hint被Oracle忽略。


參考《基於Oracle的SQL優化》

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程