赞
踩
问题描述
项目里有些报表出来的速度特别慢,尽管对润乾报表和Oracle数据库做了很多优化,效果还是不理想,这些报表普遍数据量比较大,涉及到的数据库表多(几十张)、表间关联频繁(还有自连接),报表里也有多个汇总、比值等计算。
以其中一个明细报表为例,它的SQL如下:
(select *
from (select syb.org_abbn as syb,
max(xmb.org_abbn) as xmb,
sub.org_subjection_id as sub_id,
oi.org_abbn as org_abb,
rm.rec_notice_org_id,
rm.synergic_team as xz_team,
xzdw.coding_name as xz_org,
l.requisition_cd as req_cd,
l.requisition_id as req_id,
l.note as req_note,
nvl(decode(l.ops_content6,
2000200012,
'否',
2000200011,
'是'),
'') as sflj,
--太长了,省略大部分select子句
fromlcr l
left join lcrrm on rm.requisition_id =
l.master_bill_id
andrm.table_type = '0'
andnvl(rm.bsflag, 0) != 1
left join cos sub on l.org_id = sub.org_id
andnvl(sub.bsflag, 0) != 1
left join coioi on oi.org_id = sub.org_id
andnvl(oi.bsflag, 0) != 1
--太长了,省略大部分jion
wherel.table_type = '1'
andl.requisition_state = '0101020304'
andnvl(l.bsflag, 0) != 1
andto_char(l.back_date, 'yyyy-MM-dd') between '2012-01-01' and
'2012-04-25'
group by l.requisition_id,
l.note,
l.requisition_type,
sub.org_subjection_id,
syb.org_abbreviation,
rm.rec_notice_org_id,
oi.org_abbreviation,
--太长了,省略大部分group by 字段
) a--主查询a
LEFT JOIN crviewve--视图ve
ON ve.requisition_id = a.req_id
这个sql里关联的表很多,嵌套多层子查询,最后又与一个视图进行关联(视图也很复杂)。该报表查询4个月的数据,计算时间为6分42秒,太慢了远远达不到用户要求。
我们对这个报表做过几次优化,但sql复杂度较高,基本没有优化空间,而且由于是实时查询,所以无法采用事先计算建立中间表的方法。后对这个报表进行监控发现,数据集SQL执行需要5分钟,计算展现需要1分多钟,数据集SQL慢的原因是其中两个子查询(主查询a和视图ve)做join的效率极低。
所以优化思路定为——优化数据集取数,改善SQL的join效率低的情况,顺便优化报表计算展现。
解决过程
我们是用集算器(报表厂家的东西)解决这个问题:
1、拆分原报表数据集SQL
分别把两个子查询sql写到集算器,并用switch完成关联(Switch是它的函数,比较新颖,能将外键指向的记录直接当成本记录的属性,也支持join,视不同情况使用)。
2、消除报表格间运算
将原报表模板中的比值和汇总值这些全部移到集算器中做,少了单元格遍历,报表计算速度也能提高。
3、将结果集一次返回给报表
完成所有数据准备后,把计算结果一次性返回给报表工具,报表接收到数据源后直接进行展现(不再做其他如格间计算类的影响效率的计算)。
总体代码如下:
解决效果
该报表展现时间从原来的6分42秒锐降到57秒,优化效果非常明显,超出了用户预期。其他有类似问题的报表也准备采用这个思路。
问题小结
主查询a和视图ve分别在Oracle跑时只需要10到40秒,但二者做jion却需要好几分钟,原因在于Oracle在完全自动制定查询计划的时候,并不是每次都能找到合理的方法(人工干预比较费劲)。集算器能提升性能是因为ve是a的维表,可以用特别的switch方法。由人来决定复杂查询的路径,结合Oracle的基础查询语句,速度就显著提升了。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。