oracle的hint技术,使用hint优化Oracle的执行计划

背景:

某表忽然出现查询非常缓慢的情况,cost 100+ 秒以上;严重影响生产。

原SQL:

explain plan for

select * from (

select ID id,RET_NO retNo, FROM_SYS fromSy, TO_SYS toSys, COMMAND_CODE commandCode, COMMAND, STATUS,

EXT_CODE, ORIGN_CODE orignCode,error_message errorMessage, RE_F, RET_MSG retMsg

from interface_table where ((command_code in('AASSS')

and  status in('F','E') and (re_f = 'N') and FROM_SYS = 'MEE')

or (COMMAND_CODE in('XXXX','XXXX9') and FROM_SYS = 'EXT' and RE_F = 'N')

) and MOD(id, 1) = 0  order by id) where rownum <= 100  ;

查看其执行计划:

SELECT plan_table_output FROM TABLE(DBMS_XPLAN.DISPLAY('PLAN_TABLE'));

Plan hash value: 1871549687

----------------------------------------------------------------------------------------------------

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |

----------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 99 | 382K| 637 (1)| 00:00:08 |

|* 1 | COUNT STOPKEY | | | | | |

| 2 | VIEW | | 100 | 386K| 637 (1)| 00:00:08 |

|* 3 | TABLE ACCESS BY INDEX ROWID| INTERFACE_TABLE | 355 | 55735 | 637 (1)| 00:00:08 |

|* 4 | INDEX FULL SCAN | PK_INTERFACE_TABLE | 1439 | | 280 (2)| 00:00:04 |

----------------------------------------------------------------------------------------------------

优化后的SQL:

explain plan for

select * from (

select /*+ index(INT_TABLE IX_INT_TABLE_2)*/ ID id,RET_NO retNo, FROM_SYS fromSy, TO_SYS toSys, COMMAND_CODE commandCode, COMMAND, STATUS,

EXT_CODE, ORIGN_CODE orignCode,error_message errorMessage, RE_F, RET_MSG retMsg

from interface_table where ((command_code in('AASSS')

and  status in('F','E') and (re_f = 'N') and FROM_SYS = 'MEE')

or (COMMAND_CODE in('XXXX','XXXX9') and FROM_SYS = 'EXT' and RE_F = 'N')

) and MOD(id, 1) = 0 order by id) where rownum <= 100  ;

查看其执行计划:

SELECT plan_table_output FROM TABLE(DBMS_XPLAN.DISPLAY('PLAN_TABLE'));

Plan hash value: 3625182869

--------------------------------------------------------------------------------------------------------

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |

--------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 99 | 382K| 19105 (1)| 00:03:50 |

|* 1 | COUNT STOPKEY | | | | | |

| 2 | VIEW | | 356 | 1376K| 19105 (1)| 00:03:50 |

|* 3 | SORT ORDER BY STOPKEY | | 356 | 55892 | 19105 (1)| 00:03:50 |

| 4 | CONCATENATION | | | | | |

|* 5 | TABLE ACCESS BY INDEX ROWID| INTERFACE_TABLE | 69 | 10833 | 9552 (1)| 00:01:55 |

|* 6 | INDEX RANGE SCAN | IX_INTERFACE_TABLE_2 | 77145 | | 99 (0)| 00:00:02 |

|* 7 | TABLE ACCESS BY INDEX ROWID| INTERFACE_TABLE | 287 | 45059 | 9552 (1)| 00:01:55 |

|* 8 | INDEX RANGE SCAN | IX_INTERFACE_TABLE_2 | 77145 | | 99 (0)| 00:00:02 |

--------------------------------------------------------------------------------------------------------

比较:

查看执行计划,原来是使用 full scan - 当数据量大时非常慢;优化后oracle优先走range scan,hint 的 index 是未处理标识字段的索引,正常情况下这个数据集合相对较小--------所以可以达到优化目的。

具体情况具体分析,我们必须要看实际的表存的业务数据,分析其业务关系找到最小业务集合;后者要看懂执行计划,根据rows, bytes, cost, time 找到最优项目。这个分析顺序不能倒置。

问题:为何使用 rownum 后,oracle执行计划会走full scan?

0b1331709591d260c1c78e86d0c51c18.png

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值