有这么一个匿名块...是从一个存储过程里面抽出来的
DECLARE
  IN_COMMUNITY_NAME VARCHAR2(200);
  IN_STANDARD_ADDR_NAME VARCHAR2(200);
  IN_PROD_SPEC_ID NUMBER;
  IN_BUSINESS_TYPE VARCHAR2(200);
  IN_USER_TYPE NUMBER;
  IN_AREA_ID NUMBER;
  IN_CONDITION_TYPE VARCHAR2(200);
  IN_BEGIN_ROW NUMBER;
  IN_END_ROW NUMBER;
  OUT_ATTRS RMS.PG_RMS_FOR_CRM_NEW.c_list;
  OUT_ROW_COUNT NUMBER;
  OUT_RET_CODE VARCHAR2(200);
  OUT_RET_INFO VARCHAR2(200);
  v_community_state number;
  v_gpon_not_rsc_spec varchar2(200);
  v_ocn_not_rsc_spec varchar2(200);
  V_OUT_ROW_COUNT number;
  v_start number;
BEGIN
  IN_COMMUNITY_NAME := '%田林十四村二期%';
  IN_STANDARD_ADDR_NAME := '%路%';
  IN_PROD_SPEC_ID := '';
  IN_BUSINESS_TYPE := 'FixPhone';
  IN_USER_TYPE := 1;
  IN_AREA_ID := 15;
  IN_CONDITION_TYPE := '0';
  IN_BEGIN_ROW := 1;
  IN_END_ROW := 100;
  v_community_state := 4;
  v_ocn_not_rsc_spec := '10304200';
  v_gpon_not_rsc_spec := '10102007';
  v_start := dbms_utility.get_time;select count(1) into v_out_row_count from regional_loc rl,regional_loc_2_community rl2c,community c 
where rl.geography_loc_id = rl2c.geography_loc_id and rl2c.community_id = c.community_id and rl.display_type_cd = 1 
and c.status = 4
and rl.description like IN_STANDARD_ADDR_NAME  and c.name like  IN_COMMUNITY_NAME
and rl.regional_simple_spell like '%%' and c.community_simple_spell like '%%'
and rl.user_type_id in ( 1 ,3) 
and c.rsc_spec_id <> v_ocn_not_rsc_spec 
and c.rsc_spec_id <> v_gpon_not_rsc_spec
and rl.area_id = 15 ;DBMS_OUTPUT.PUT_LINE('OUT_ROW_COUNT = ' || v_out_row_count);dbms_output.put_line('time = ' || (dbms_utility.get_time - v_start) * 10);
END;
执行这个块的结果是:
OUT_ROW_COUNT = 32
time = 940然后我把块里面的SQL条件改成
and rl.description like '%路%'  and c.name like  IN_COMMUNITY_NAME
其他没变
执行结果是
OUT_ROW_COUNT = 32
time = 0
这个速度差异怎么这么大?各位帮看看有什么办法优化一下吗?
我使用自动跟踪...这2个块的结果分别是:第一个---
recursive calls 8
db block gets 0
consistent gets 15218
physical reads 0
redo size 0
bytes sent via SQL*Net to client 617
bytes received via SQL*Net from client 2970
SQL*Net roundtrips to/from client 2
sorts (memory) 2
sorts (disk) 0第二个--------
recursive calls 9
db block gets 0
consistent gets 200
physical reads 0
redo size 0
bytes sent via SQL*Net to client 617
bytes received via SQL*Net from client 2956
SQL*Net roundtrips to/from client 2
sorts (memory) 1
sorts (disk) 0

解决方案 »

  1.   

    consistent gets 15218差异在这里,lz自己去找答案吧!
      

  2.   

    我知道差异在这...我就是想问问有什么解决办法....
    毕竟这个SQL单独执行很快的..只要0.几秒...所以应该不是表的优化问题...
    我只不过把条件用个变量绑定之后就慢了这么多..所以想问问是什么原因造成的..该怎么解决...
      

  3.   


    很简单,你觉得绑定变量应该什么时候用?大批量执行重复的语句用绑定,可以避免反复硬解析。一个查询语句,你直接把值写死,SQL优化器会根据统计信息去制订执行计划,反而可能更好。用绑定,它只能在变量传入之前就制订执行计划,无法进一步根据统计信息去优化