有些報表查詢出的資料行數可達千萬甚至上億，這類報表通常被叫做大報表，大多數情況下都是些清單明細資料包表，也有少量分組報表。

針對大報表，如果像常規報表一樣，將資料一次性全取再交給前端呈現是不可行的。一是等待時間太長，使用者體驗差；二是很可能導致記憶體溢位造成應用崩潰。

那麼，目前的報表產品是如何解決這一問題的呢？本文將調研並測試幾款報表產品的大報表解決方案，還是針對這三款產品：潤乾報表、帆軟報表、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 ASCSELECT *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 e1ORDER BY 訂單ID DESC) AS e2ORDER BY 訂單ID ASC

注：不同的資料庫，寫法不同。

新計算引擎

新計算引擎可以替代行式引擎的功能，使得做報表變的簡單，比如對於 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 在效能容量方對比潤乾和帆軟則有明顯的差距，面對大容量和高效能場景只能勉強甚至無法應對，能力要弱一個檔次。