首页 / 数据库 / MySQL / 使用hint优化Oracle的执行计划

背景：某表忽然出现查询非常缓慢的情况，cost 100+ 秒以上；严重影响生产。Oracle入门教程：leading vs ordered hint  http://www.linuxidc.com/Linux/2012-03/56769.htmOracle hint 实践一列 leanding 驱动表和hash多块读取 http://www.linuxidc.com/Linux/2012-01/52039.htmOracle优化常用hint语句 http://www.linuxidc.com/Linux/2011-09/43104.htmOracle调优hint提示 http://www.linuxidc.com/Linux/2011-09/43103.htm原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"））;

1. Plan hash value: 1871549687
3. ----------------------------------------------------------------------------------------------------
4. | Id | Operation | Name | Rows | Bytes | Cost （%CPU）| Time |
5. ----------------------------------------------------------------------------------------------------
6. | 0 | SELECT STATEMENT | | 99 | 382K| 637 （1）| 00:00:08 |
7. |* 1 | COUNT STOPKEY | | | | | |
8. | 2 | VIEW | | 100 | 386K| 637 （1）| 00:00:08 |
9. |* 3 | TABLE ACCESS BY INDEX ROWID| INTERFACE_TABLE | 355 | 55735 | 637 （1）| 00:00:08 |
10. |* 4 | INDEX FULL SCAN | PK_INTERFACE_TABLE | 1439 | | 280 （2）| 00:00:04 |
11. ----------------------------------------------------------------------------------------------------

优化后的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"））;

1. Plan hash value: 3625182869
3. --------------------------------------------------------------------------------------------------------
4. | Id | Operation | Name | Rows | Bytes | Cost （%CPU）| Time |
5. --------------------------------------------------------------------------------------------------------
6. | 0 | SELECT STATEMENT | | 99 | 382K| 19105 （1）| 00:03:50 |
7. |* 1 | COUNT STOPKEY | | | | | |
8. | 2 | VIEW | | 356 | 1376K| 19105 （1）| 00:03:50 |
9. |* 3 | SORT ORDER BY STOPKEY | | 356 | 55892 | 19105 （1）| 00:03:50 |
10. | 4 | CONCATENATION | | | | | |
11. |* 5 | TABLE ACCESS BY INDEX ROWID| INTERFACE_TABLE | 69 | 10833 | 9552 （1）| 00:01:55 |
12. |* 6 | INDEX RANGE SCAN | IX_INTERFACE_TABLE_2 | 77145 | | 99 （0）| 00:00:02 |
13. |* 7 | TABLE ACCESS BY INDEX ROWID| INTERFACE_TABLE | 287 | 45059 | 9552 （1）| 00:01:55 |
14. |* 8 | INDEX RANGE SCAN | IX_INTERFACE_TABLE_2 | 77145 | | 99 （0）| 00:00:02 |
15. --------------------------------------------------------------------------------------------------------

比较：查看执行计划，原来是使用 full scan - 当数据量大时非常慢；优化后oracle优先走range scan，hint 的 index 是未处理标识字段的索引，正常情况下这个数据集合相对较小--------所以可以达到优化目的。具体情况具体分析，我们必须要看实际的表存的业务数据，分析其业务关系找到最小业务集合；后者要看懂执行计划，根据rows, bytes, cost, time 找到最优项目。这个分析顺序不能倒置。问题：为何使用 rownum 后，oracle执行计划会走full scan？本文永久更新链接地址