一个存储过程执行速度的问题............

[talentwing]

有这么一个匿名块...是从一个存储过程里面抽出来的

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

[啊彪123]

consistent gets 15218

差异在这里，lz自己去找答案吧！

[talentwing]

[Quote=引用 1 楼 的回复:]

SQL code
consistent gets 15218
差异在这里，lz自己去找答案吧！
[/Quote]
我知道差异在这...我就是想问问有什么解决办法....
毕竟这个SQL单独执行很快的..只要0.几秒...所以应该不是表的优化问题...
我只不过把条件用个变量绑定之后就慢了这么多..所以想问问是什么原因造成的..该怎么解决...

[forgetsam]

[Quote=引用 2 楼 的回复:]

引用 1 楼 的回复:

SQL code
consistent gets 15218
差异在这里，lz自己去找答案吧！

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

很简单，你觉得绑定变量应该什么时候用？

大批量执行重复的语句用绑定，可以避免反复硬解析。

一个查询语句，你直接把值写死，SQL优化器会根据统计信息去制订执行计划，反而可能更好。

用绑定，它只能在变量传入之前就制订执行计划，无法进一步根据统计信息去优化

[talentwing]

[Quote=引用 3 楼 的回复:]

引用 2 楼 的回复:

引用 1 楼 的回复:

SQL code
consistent gets 15218
差异在这里，lz自己去找答案吧！

我知道差异在这...我就是想问问有什么解决办法....
毕竟这个SQL单独执行很快的..只要0.几秒...所以应该不是表的优化问题...
我只不过把条件用个变量绑定之后就慢了这么多..所以想问问是什么原因造成的..该怎么解决……
[/Quote]
那意思就是没法优化了?...绑定的变量是要通过外部当做参数传进来..每次查询的条件都不一样...