报表性能优化系列专题一

blueideas

第一节、      从细节入手

尽量不用select * from
FineReport报表的数据集采用的是表模型，也就是说通过SQL这种DSL语言，从数据库通过简单查询或各种组合关联查询得到一个关系表，而这部分SQL查询根据各种数据库产商长时间的优化(比如建立索引)，已经非常成熟。而这些表结构数据集一般要通过FineReport报表模型的复杂处理才能生成最终的表样。因此，从数据库sql查询取出数据量越少，FineReport报表模型需要做的复杂处理和计算就越少，所化的时间和内存就少了，从而可以提高性能表现。
sql初学者刚开始时往往会忽略sql的写法细节。然而sql优化却是性能优化中十分关键的一点，有时候sql优化的好的话，可以大大提高性能。比如slect * from table1这种写法，就比较粗糙，没有经过优化，在数量不是很大时或许没问题，但是如果数据量很大的话，此处就是一个很好的优化点。

如上图所示，初级用户经常直接拖拽表名，点菜单后就没有再做处理，这在某些性能敏感的报表中是个不好的习惯。例如报表中只需要用到三个字段，但是数据库中实际的表有十个字段，一些初学者习惯性的用select * from table1，这样相当于把十个字段的数据都取到报表服务器端，增加了报表服务器端的内存占用以及减慢了运算速度
正确的写法是：select col1,col2,col3 from table1，即用到哪几个字段就取哪几个，用不着的不要取。从重要的细节入手，有时候会带来很好效果。



第二节、
尽量在sql里分组

对于汇总类型的报表，往往需要进行分组聚集运算，如果在数据库中先进行一次分组聚集，能够大大减少取到报表服务器的记录数，加快取数和报表运算的速度。
看如下报表：


这是一个典型的交叉分组报表，其sql有两种写法：
第一种：SELECT Region, Product, Amount FROM sale



第二种：SELECT Region, Product, sum(Amount) FROM sale group by Region, Product



而报表的做法都一样，如下图所示：



优化分析：
第一种做法，不仅仅取到报表服务器上记录数多了，取数速度慢，而且报表模型需要对表数据列进行分组运算，增加了报表运行时间；
第二种做法，数据库虽然要进行分组运算，但是数据库中有索引，运算速度快，且取到报表服务器端的记录数大大减少，取数速度大大加快，因此在报表模型进行分组运算的时候只要对很少的记录数进行，报表的运算速度大大加快了。
实验结果以及分析表明，第二种做法的性能远优于第一种。所以，分组应该尽量在sql里进行。

第三节、
尽量在sql里排序

跟分组同样的道理，报表中往往需要对数据进行排序，排序运算可以在数据库中进行，也可以在报表端进行，如果报表中的排序规则是确定的，那么建议排序操作选择在数据库端进行，因为数据库中有索引，通常是C/C++语言(往往在效率上比Java好)写的，数据运算速度快。下面以一个简单的分组报表为例：
如果排序是在sql里面进行，则sql里面写SELECT Manager, Product, Amount FROM sale order by Manager，如下：



报表的做法，也很简单，直接拖拽数据列，设置格式，如下：



这样做时，数据集ds1中对Manager数据列已经排好了序，所以报表模型不需要对数据列做任何处理，并且取数时是顺序的从数据集中依次从上倒下取数，只需遍历一遍，从而节省了时间，优化了性能。
如果排序不在sql中进行

则需要在数据列Manager的高级面板中对排序进行设定，设为升序




所以，从实验结果可以看出，排序在sql里进行是个优化性能的好办法。

第四节、
尽量在sql里过滤

这个问题和分组及排序是类似的，报表很多时候并不需要对表中的所有记录进行操作，而是对部分满足条件的记录进行操作，因此建议过滤操作在数据库中进行，这样取到报表服务器端的记录数大大减少，既加快了取数的速度，也加快了报表的运算速度，因为报表需要处理的数据少了。
依然那销售记录表举例：
如果我们要取Amount超过300的记录，在sql中写SELECT Manager, Product, Amount FROM sale where Amount > 300
如下图：



如果不在sql里面进行过滤，则需要在数据列的过滤面板中进行设置，如下



直接在sql中过滤，要比在数据列过滤面板中设置过滤，效率高很多。所以，考虑到性能，尽量在sql中进行过滤。


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/17568/showart_2164295.html