oracle数据源的报表sql计算慢&解决

问题描述

项目里有些报表出来的速度特别慢，尽管对润乾报表和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的基础查询语句，速度就显著提升了。