使用leading(,)优化sql执行计划.doc

使用leading(,)优化sql执行计划 使用leading(,)优化sql执行计划 个人分类：优化案例 今天在数据库中捕获到一条sql，其cost很小但是逻辑读又极高，sql大致如下 select count(*) from JUSTIN_REFER u_f left join JUSTIN u on u_f.refer_id = u.id where u.ip =:a; 一般来说对于cost极小但是buffer gets又很高的语句，大多是由统计信息不准确造成的， 但是这两个表都是7月份收集的，且两个表的数据改动都是很平稳的，不应该是统计信息出错。 SQL select table_name,last_analyzed from user_tables where table_name in(JUSTIN_REFER,JUSTIN); TABLE_NAME LAST_ANALYZED JUSTIN 2011-7-27 上午 JUSTIN_REFER 2011-7-2 上午 查看一下绑定变量的历史记录 SQL select value_string,count(*) from dba_hist_sqlbind where sql_id =dsc850x8y7can group by value_string; VALUE_STRING COUNT(*) 180.a.b.c 1 222.a.b.c 401 58.a.b.c 1 60.a.b.c 1 218.a.b.c 1 可以看到大部分时候都是选择222.a.b.c作为绑定值，采用autotrace查看一下其执行计划 SQL set autotrace traceonly SQL set linesize 300 pagesize 300 SQL variable a varchar2(200); SQL exec :a := 222.a.b.c; PL/SQL procedure successfully completed. SQL select count(*) 2 from JUSTIN_REFER u_f 3 join JUSTIN u 4 on u_f.refer_id = u.id 5 where u.ip = :a; | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | | 0 | SELECT STATEMENT | | 1 | 19 | 9 (0)| 00:00:01 | | 1 | SORT AGGREGATE | | 1 | 19 | | | | 2 | NESTED LOOPS | | 11 | 209 | 9 (0)| 00:00:01 | | 3 | TABLE ACCESS BY INDEX ROWID| JUSTIN |