安科网

Oracle中Hint被忽略的几种常见情形

treasurelifelhf

treasurelifelhf

2017-03-24

关注 关注

Hint可以影响优化器对于执行计划的选择，但这种影响不是强制性的，优化器在某些情况下可能会忽略目标SQL中的Hint。由于各种原因导致Hint被Oracle忽略后，Oracle并不会给出任何提示或者警告，更不会报错，目标SQL依然可以正常运行，这也符合Hint实际上是一种特殊注释的身份。注释本来就是可有可无的东西，不应该因为它的存在而而导致原先在没有Hint时可以正常执行的SQL因为加了Hint后而变得不能正常执行。

下面来看几种Hint被Oracle忽略的常见情形。

1 使用的Hint有语法或者拼写错误

一旦使用的Hint中有语法或者拼写错误，Oracle就会忽略该Hint，看几个示例SQL：

select /*+ ind(emp pk_emp) */* from emp;

select /*+ index(emp pk_emp */* from emp;

select /* + index(emp pk_emp) */* from emp;

select */*+ index(emp pk_emp) */ from emp;

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

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

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

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:

  1 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：

  1 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忽略。

select oracle emp oracle执行计划

treasurelifelhf

treasurelifelhf

0 关注 0 粉丝 0 动态

关注 关注

相关推荐

oracle锁表该如何解决

where l.object_id　=　o.object_id and l.session_id=s.sid;如果杀不掉可以加个 immediate 立即杀掉 试试；如果利用上面的命令杀死一个进程后，进程状态被置为"killed"，但是

oraclemch 2020-11-06

oracle 日期操作语句总结

SELECT TO_CHAR AS YEAR FROM DUAL--查询当前年份。SELECT TO_CHAR AS MONTH FROM DUAL--获取当前日期的'YYYY/MM/DD'格式：2020/01/02. SELECT TO_CHAR AS

Seandba 2020-08-16

ORACLE数据库中Rownum用法详解

ORACLE 中ROWNUM用法总结!对于 Oracle 的 rownum 问题，很多资料都说不支持>,>=,=,between...and，只能用以上符号(<、<=、!=)，并非说用>,& gt;=,=,betwee

dbasunny 2020-08-16

oracle 授予权限和收回权限 grant和revoke 以及角色的创建 删除

ALLON数据对象名,SELECTON数据对象名,UPDATEON数据对象名,DELETEON数据对象名,INSERTON数据对象名,--用户授权GRANTCONNECT,RESOURCETO用户名;GRANTSELECTON表名TO用户名;GRANTSE

娜娜 2020-06-22

Golang 定时器(Timer 和 Ticker),这篇文章就够了

Golang 原生 time 包下可以用来执行一些定时任务或者是周期性的任务的一个工具。本文基于 Go 1.14，如果以下文章有哪里不对或者问题的地方，欢迎讨论学习。定时器的日常使用。timer.Stop() // 这里来提高 timer 的回收。tCha

专注前端开发 2020-10-21

Mysql 实现字段拼接的三个函数

给运营导出数据时，难免需要对字段进行拼接，如果 Mysql 可以完成的话，就可以少些很多代码。不过如果有字段值为 NULL，则结果为 NULL。上面这种方式如果想要使用分隔符分割，就需要每个字段中间插一个字符串，非常麻烦。concat_ws() 可以一次性

苏康申 2020-11-13

详解 MySQL中count函数的正确使用方法

当搞清楚count函数的运行原理后，相信上面几个问题的答案就会了然于胸。为了解决上述的问题，我创建了一张 user 表，它有两个字段：主键id和name，后者可以为null，建表语句如下。`id` int NOT NULL AUTO_INCREMENT C

vitasfly 2020-11-12

SQL Server如何通过创建临时表遍历更新数据详解

前段时间新项目上线为了赶进度很多模块的功能都没有经过详细的测试导致了生成环境中的数据和实际数据对不上，因此需要自己手写一个数据库脚本来更新下之前的数据。关于数据统计汇总的问题肯定会用到遍历统计汇总，那么问题来了数据库中如何遍历呢？好像并没有for和fore

liuyang000 2020-09-25

ThinkPHP5 链式操作table用法

table方法主要用于指定操作的数据表。用法一般情况下，操作模型的时候系统能够自动识别当前对应的数据表，所以，使用table方法的情况通常是为了：。需要注意的是table方法不会改变数据库的连接，所以你要确保当前连接的用户有权限操作相应的数据库和数据表。切

FellowYourHeart 2020-10-05

sql注入 --显错注入

jiong 2020-09-17

Orcle11G创建表空间，创建用户，授权等操作

CREATE USER caiyl IDENTIFIED BY 123456 DEFAULT TABLESPACE caiyl_space;GRANT CREATE USER,DROP USER,ALTER USER ,CREATE ANY VIEW ,A

赵继业 2020-08-17

SQL 创建、更新和删除视图的方法

视图是可视化的表。本章讲解如何创建、更新和删除视图。视图包含行和列，就像一个真实的表。您可以向视图添加 SQL 函数、WHERE 以及 JOIN 语句，也可以呈现数据，就像这些数据来自于某个单一的表一样。视图 "Current Product L

whyname 2020-08-16

MySQL如何创建视图

可以使用 CREATE VIEW 语句来创建视图。该名称在数据库中必须是唯一的，不能与其他表或视图同名。用户除了拥有 CREATE VIEW 权限外，还具有操作中涉及的基础表和其他视图的相关权限。SELECT 语句不能包含 FROM 子句中的子查询。可使用

拼命工作好好玩 2020-08-15

详细分析mysql视图的原理及使用方法

在MySQL中，视图可能是我们最常用的数据库对象之一了。那么你知道视图和表的区别吗？可能很多人对视图只是一知半解，想详细了解视图的同学看过来哟，本篇文章会详细介绍视图的概念、创建及使用方法。当我们创建一个视图的时候，实际上是在数据库里执行了SELECT语句

langyue 2020-08-15

MySQL约束

分别查询男、女同学的平均分,人数 要求：分数低于70分的人，不参与分组,分组之后。

好记忆也需烂 2020-08-15

MySQL实现根据当前ID读取上一条和下一条记录

SELECT * FROM A WHERE ID < 5 ORDER BY ID DESC LIMIT 0,1; ps: select * from table1 where id<$id order by iddesc limit

写程序的赵童鞋 2020-08-03

mysql 14 覆盖索引+回表

MySQL可以利用索引返回select列表中的字段值。而不必根据主键再次读取聚簇索引数据文件查到数据，也就是平时所说的不需要回表操作。覆盖索引其实是索引覆盖的意思，索引字段就已经囊括select查询的字段，即索引字段覆盖了需查询的字段。t; 即id是聚集索

Accpcjg 2020-08-02

go语言中——select的使用方法

早期的select函数是用来监控一系列的文件句柄，一旦其中一个文件句柄发生IO操作，该select调用就会被返回。golang在语言级别直接支持select，用于处理异步IO问题。可以看出，ch初始化后，case1读取失败，timeout同样失败，因为ch

tydldd 2020-07-30

Mysql入门 DML语句大全DML、DDL、DCL

Mysql 数据库语句 1、说明：创建数据库CREATE DATABASE database-name2、说明：删除数据库drop database dbname3、说明：备份sql server--- 创建 备份数据的 deviceUSE masterE

好记忆也需烂 2020-07-28

fiddler相关命令的使用

bps 后边跟的是 HTTP 状态码，表示中断所有为该状态码的会话。将所有的会话打包成 .zip 压缩包的形式保存到 C 盘根目录下。比如 urlreplace baidu fishc 表示将所有 URL 的 baidu 替换成 fishc。select

jianghero 2020-07-28
treasurelifelhf

treasurelifelhf

W3CSchool教程
HTML 教程
CSS 教程
Bootstrap 教程
Javascript 教程
jQuery 教程
后端教程
C 教程
Java 教程
PHP 教程
Python 教程
Go 教程
移动开发
Android 教程
Swift 教程
Kotlin 教程
jQuery Mobile 教程
ionic 教程
关于我们
新闻动态
联系方式
招聘英才
安科实验室
帮助与反馈

安科网(Ancii)，中国第一极客网

Copyright © 2013 - 2019 Ancii.com

京ICP备18063983号 京公网安备11010802014868号