delete相关的pl/sql调优(r4笔记第87天)

今天开发找到我，说有个问题想征求一下我的意见。

DECLARE

FOR C1 IN (select *from bpm_context_instselect /*+ PARALLEL(coll_entity_history 4) */ proc_inst_id from coll_entity_history where END_TREATMENT_DATE >= SYSDATE -5 and END_TREATMENT_DATE <= SYSDATE -1 )))

END;oll_entity_history 不需要做索引扫描，可以走全表扫描，他们认为就万事大吉了。但是我一看到上面的cursor中的那段代码，就开始担心了。

65788	2-Mar-15
30787	7-Feb-15
7987	11-Mar-15
33929	6-Feb-15
29370	10-Feb-15
53211	26-Feb-15
62	23-Mar-15
3382	17-Mar-15
4443	4-Mar-15
12095	13-Feb-15
8789	12-Feb-15
3074	13-Mar-15
7598	20-Feb-15
2239	8-Mar-15
2627	14-Mar-15
7726	24-Feb-15
6330	22-Feb-15
6537	19-Feb-15
7158	21-Feb-15
2872	7-Mar-15
7419	18-Feb-15
5104	9-Mar-15
46094	27-Feb-15
18377	4-Feb-15
7571	16-Feb-15
4145	6-Mar-15
4006	16-Mar-15
20	24-Mar-15
7578	17-Feb-15
29062	9-Feb-15
6821	15-Feb-15
886	18-Mar-15
9221	25-Feb-15
3822	10-Mar-15
953	20-Mar-15
62115	5-Mar-15
2484	15-Mar-15
26311	8-Feb-15
6997	14-Feb-15
16572	28-Feb-15
68	26-Mar-15
11202	11-Feb-15
9251	1-Mar-15
5056	22-Mar-15
2869	21-Mar-15
29508	5-Feb-15
1	25-Mar-15
493	19-Mar-15
55572	3-Mar-15
7469	23-Feb-15
5008	12-Mar-15

按照这个数据量，原本存在性能隐患的那段pl/sql看起来也顺眼多了。但是细细看来，还是有个硬伤。就是cursor定义的部分，根据pl/sql的实现目标，没有用到clob字段，所以是不相关的。可以在cursor的部分直接过滤掉。C1 IN (select *from bpm_context_inst where objid in (select context_inst2context_inst from bpm_proc_inst where objid in (select /*+ PARALLEL(coll_entity_history 4) */ proc_inst_id from coll_entity_history where END_TREATMENT_DATE >= SYSDATE -5 and END_TREATMENT_DATE <= SYSDATE -1 ))) 直接改为select objid from bpm_context_inst就可以了最后我给出了两种意见，第一种是上面的pl/sql完全可以通过一句delete语句来完成，至于他们关注的分段提交，其实在这个场景中，影响是忽略不计，实际上一次提交性能还要好于分批提交。即delete bpm_context_inst where objid in (select context_inst2context_inst from bpm_proc_inst where objid in (select /*+ PARALLEL(coll_entity_history 4) */ proc_inst_id from coll_entity_history where END_TREATMENT_DATE >= SYSDATE -5 and END_TREATMENT_DATE <= SYSDATE -1 ))另外一种就是把cursor定义的部分做一些改动，去除clob字段。对于cursor的提升是还是很大的。对于这两种意见，开发同事说自己确实考虑得不够周到，不过为了避免给客户造成更多的困扰，还是选用第二种方案。这个问题带给我的启示就是可能大家问你的问题是一个场景，但是和另外一个场景联系起来，原来的一些推论就不是那么肯定了。就比如这个问题中，开发确定不需要索引对于查询这个表性能影响不大，但是并不意味着在和其他的大表关联时没有问题。如果那种情况发生，还需要做一些额外的优化工作。根据数据量最后得知，变更的数据量很小，所以这个也算是化险为夷吧。