有些报表查询出的数据行数可达千万甚至上亿，这类报表通常被叫做大报表，大多数情况下都是些清单明细数据报表，也有少量分组报表。
针对大报表，如果像常规报表一样，将数据一次性全取再交给前端呈现是不可行的。一是等待时间太长，用户体验差；二是很可能导致内存溢出造成应用崩溃。
那么，目前的报表产品是如何解决这一问题的呢？本文将调研并测试几款报表产品的大报表解决方案，还是针对这三款产品：润乾报表、帆软报表、Smartbi，均为最新版本。
首先了解下各家的解决方式或机制。
解决机制
帆软
帆软提供两种引擎，行式引擎专门解决明细大报表，新计算引擎可解决行式引擎及其不支持的一些情况（如某些数据库需手写分页 SQL 的问题、分组大报表、带汇总的分组报表等）。
行式引擎
实现原理是借助分页 SQL 按页取数，访问哪一页数据则取对应数据计算并呈现，所以也只能支持数据库源了。并且只有少部分数据库可以不改动 SQL 的情况下支持分页取数： Oracle，MySQL，HSQL 和 SQL Server 2012 及以上数据库。像其他的 access、SQL Server 2005 及 2008 等，必须手动编写分页 SQL 才能实现按页取数。可以看个例子感觉难易度：
原始 SQL：select * from 订单明细
SQL Server 2008 下的分页 SQL 为：
SELECT *
FROM (
SELECT TOP ${ if(fr_pagenumber == int((((fr_rowcount-1)/fr_pagesize)+1)),fr_rowcount - (fr_pagesize*(fr_pagenumber-1)),fr_pagesize) } *
FROM(
SELECT TOP ${fr_pagesize*fr_pagenumber} *
FROM 订单明细
ORDER BY 订单ID ASC
) AS e1
ORDER BY 订单ID DESC
) AS e2
ORDER BY 订单ID ASC
SELECT*FROM(SELECTTOP ${if(fr_pagenumber ==int((((fr_rowcount-1)/fr_pagesize)+1)),fr_rowcount - (fr_pagesize*(fr_pagenumber-1)),fr_pagesize) } *FROM(SELECTTOP ${fr_pagesize*fr_pagenumber} *FROM订单明细ORDERBY订单IDASC)ASe1ORDERBY订单IDDESC)ASe2ORDERBY订单IDASC
注：不同的数据库，写法不同。
新计算引擎
新计算引擎可以替代行式引擎的功能，使得做报表变的简单，比如对于 SQL Server 较低版本，不用再单独写分页 SQL，新计算引擎会把原本 SQL 处理成分页 SQL。但是原理不完全一样，行式引擎是按页取数（页面大小或页行数），新计算引擎则是每次按 1024 条（不支持自定义）为一个区间分批取数。
报表格式上也能支持分组大报表、带汇总的分组表。
帆软这两个引擎都是借助数据库分页机制，仅支持 SQL 数据源。新计算引擎的优势在于可以让定义 SQL 时更简单，如上面所提到的明细大报表按页取数手写分页 SQL 的问题，新引擎不用自己搞了。
使用数据库分页有几个共同的缺点：1、频繁反复翻页时效率很差，特别是靠后的页，对数据库造成很大压力；2、可能出现数据不一致（两次执行取数 SQL 之间有插入、删除动作）；3、不支持其他类型数据源。
Smartbi
Smartbi 只能借助数据库 SQL 分页，因此仅支持 SQL 数据源，且报表格式仅支持明细报表，该机制缺点同帆软。
润乾
两阶段双异步线程
可参考下图
以 SQL 数据源为例，取数和呈现采用两个异步线程，取数线程发出 SQL 后，游标方式不断取出数据缓存到本地磁盘，由呈现线程从本地缓存中获取数据进行显示。这样，已经取出并缓存的数据就能快速呈现，不再有等待感；而取数线程所涉及的 SQL，在数据库中保持同一个事务，也不会有不一致的问题，数据库分页机制的两大问题（SQL 分页数据不一致、翻页效率差）都可以完美解决。
采用该机制，首页可实现秒级响应，缓存是在硬盘，内存占用小，可有效避免内存溢出。
另外，该机制同样支持非 SQL 数据源，包括文件数据源、noSQL 数据源、接口数据源等。
同时，报表格式上支持明细大报表、带汇总及分组大报表等，具体做法这里不再赘述，有更详细的文章介绍：如何实现海量数据清单和分组报表
用例及测试结果
用例
通过以上了解的各产品支持情况，我们用大家都支持的大数据明细报表做个对比，看看首页呈现、翻页等的效率及体验。
数据库：MySQL 5.7
“各城市产品销售表”，620 万条 *6 列数据。
JVM：可用 1G，数据无法全部加载。
测试结果
报表按照每页 30 行 *6 列呈现。
从测试结果可以看出，润乾的首页加载及翻页体验最好，均可做到秒级响应。
帆软次之，看测试结果的话，新计算引擎体验上比行式引擎要好，但是目前功能不完善，如分页仅支持按页面大小，不支持其他方式等。在后面测试分组报表时也对这些不完善得到了印证，查询靠后的页码时，因 SQL 时间执行过长挂掉了，即便改了系统等待 SQL 执行时间，那也没法用了，等待时间太长，体验太差。这些问题在帆软官方客服那里也能被确认，新计算引擎新推出不久（看文档，貌似也近一年时间了），功能不完善，很多都是需要优化的状态。
Smartbi 也是数据库分页机制，但表现很差（尝试降低查询总数据量到 26 万，也需要 25s 左右），按测试用例结果来看，几乎是没法用的。
分组报表
Smartbi 直接不支持分组大报表，帆软在翻页时几乎没法用，只有润乾可以正常实现，这样就无法实施对比了。润乾实现方法可参考：海量清单与分组报表的实现
性能测试结论
本篇之前还有三篇材料：
我们从四个方面对这三款报表工具进行了深入的性能测试对比。基本上每篇的结论都相同，即润乾报表的性能和容量最好、内核引擎最优；帆软次之，每个对比项上均有差距，但大部分项目差距并不算大。这两款均可以算作第一档次的报表工具，基本可以胜任大部分大容量和高性能场景。而 Smartbi 在性能容量方对比润乾和帆软则有明显的差距，面对大容量和高性能场景只能勉强甚至无法应对，能力要弱一个档次。
