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的提升是还是很大的。对于这两种意见，开发同事说自己确实考虑得不够周到，不过为了避免给客户造成更多的困扰，还是选用第二种方案。这个问题带给我的启示就是可能大家问你的问题是一个场景，但是和另外一个场景联系起来，原来的一些推论就不是那么肯定了。就比如这个问题中，开发确定不需要索引对于查询这个表性能影响不大，但是并不意味着在和其他的大表关联时没有问题。如果那种情况发生，还需要做一些额外的优化工作。根据数据量最后得知，变更的数据量很小，所以这个也算是化险为夷吧。