网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
通过这些实际案例可以看出，使用SPL实现了高效的算法后，在SQL无法解决的性能问题中，可能获得数倍以至数十甚至上百倍的性能提升
到这里我们可能会想，解决个性能问题还得把原先的SQL甚至是存储方式都舍弃，全部用新的SPL重新做,这也太费劲了，代价太大了吧
是的，小问题是没这个必要折腾，但是遇上重病那就只能用猛药来医了，当现有的SQL已经无法再继续优化，性能问题已经没办法解决时，那就只能尝试用新的办法来解决了
而且体会过更高效的算法以后，使用新技术估计也不会再是一种迫不得已的选择了，而是会变成更主动自愿的拥抱了
另外一些报表工具已经集成了开源的SPL了，比如润乾报表，直接用这样的工具来做报表，解决起问题来也更直接方便一些
数据传输的问题和优化
报表项目大部分都是JAVA应用，基本都得通过JDBC来取数、做数据传输，有时候我们会发现，SQL很简单，数据库负担也很轻，但数据传输到报表却需要很长时间，传输完成后，报表也算的很快，那就可以判定，就是有些数据库的JDBC取数太慢，导致了性能问题
这是DB本身的问题，怎么优化？
我们动不了厂商的JDBC，那就只能曲线救国，单线程取的慢，如果数据库允许，我们可以尝试多线程并行取，如果报表工具有并行取数的功能，那问题就迎刃而解了，但由于并行取数涉及的数据分段方法和数据库及取数语法需要较复杂代码控制，也不容易做成报表功能，所以目前的报表工具基本都不支持并行取数，那就又得再外围实现了
外围实现，可以是自己用java等高级语言去写，但是会复杂一些，工作量也不小，也可以用现成的计算工具去做，比如前面提到的SPL就可以轻松支持并行计算，下图就是SPL并行取数的代码，写起来还是很简单的，也容易理解
在数据库负担不重时，并行取数几乎可以让传输效率得到线性的提升
附上一个并行取数和单线程取数的性能测试对比，感兴趣的同学可以去看看
同样的，如果报表工具中集成了SPL，那也就可以通过并行取数来提升性能了
其他环节的问题和优化
报表内计算和呈现
前两个重点的环节看完了，大头已经解决了，不过还是有些报表的性能问题出在后面的环节中，我们来看下，后两个环节是报表内的计算和呈现
先看计算
报表内的计算，首先要看报表工具的基本功，另一方面也要看外围计算引擎，基本功好，可以保证大部分表内计算都不出问题，有外部计算引擎，可以保证特殊情况也运行无恙
我们以业界性能口碑比较好的润乾报表为例，即使它在相同条件下各类报表，各种计算的性能都优于同类产品，但由于报表工具本身定位的局限性，再好的工具也不可能任何情况下都跑的快，遇到跑不快的情况，工具本身没有优化空间时，那就还得借助外部计算引擎的能力才行
举个最简单的例子，比如要在报表里做多源关联，我们需要写一个类似这样的表达式ds2.select(ID==ds1.ID)，表达式很简单，但是计算复杂度却是平方级的，数据量不大时，都没问题，数据量稍大时，到几千行，那性能就会急剧下降了，再好的工具处理这样的运算也会有问题
但如果把这个关联放到报表外来做，利用外部的计算引擎计算能力，可以使用低复杂的HASH算法（而在报表工具中无法对多个数据源先统一处理，实现不了这种算法），那性能就会大幅度的提升了
以下是我们在数据量比较大时，用润乾报表单独运算和SPL+润乾报表协同运算的性能对比，可以看出，报表内的计算性能问题，如果挪到外部计算引擎解决，效果是非常好的
（蓝色是润乾报表单独运算的时间，橙色是SPL+润乾报表协同运算的时间）
再看呈现
这个就完全看报表本身的能力了，没有其他外围方式可以协助和利用了，如果呈现环节总出问题，那就得考虑换工具了
附上一个如何考察报表工具本身计算和呈现性能的帖子，有需要的可以参考：
大报表
报表性能问题们还有一个场景需要注意，就是大清单式报表，比如电信行业，要查看当月所有的充值记录，这样的报表，格式简单，但是数据量极大，有的可达到千万级以上，这类大数据量的报表呈现时如果等着把这些记录全部检索出来再生成报表，那会需要很长时间，用户体验自然会非常恶劣，而且报表一般采用内存运算机制，大多数情况下内存里也装不下这么多数据，所以我们一般都会使用分页呈现的方式，尽量快速地呈现出第一页，之后再通过翻页来加载后面的
这种分页呈现的方式通常是利用数据库的分页机制来实现，但数据库分页不仅有如下这些弊端，而且程序代码和对应的数据库是强耦合的，万一换了数据源，那还得重新做一遍
更好的方式是，取数和呈现做成两个异步线程，取数线程发出 SQL 后就不断取出数据后缓存到本地存储中，呈现线程根据页数计算出行数到本地缓存中去获取数据显示，如下图所示
通过这样的方式，就可以很好的解决大数据量清单式报表的性能难题了具体如何实现可以参考：大清单报表该怎么做？
总结
从前面所述的几个优化过程中可以看出，大部分性能问题，都是在报表工具外做的优化，数据准备在报表外，数据传输在报表外，表内计算慢时，大部分也可以挪到报表外，只有呈现这一个环节是报表内的
所以单凭一个报表工具想完全解决报表的性能问题是不太可能的，要真正彻底的解决性能难题，除了看报表本身的性能外，更需要重点看工具有没有外围的计算引擎来协助，报表本身能力强，又有计算引擎帮忙（类似内置了开源SPL的润乾报表），一套组合拳打下来，报表性能问题才能真正解决
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
戳这里获取](https://bbs.csdn.net/topics/618545628)**
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
