大清單報表應當怎麼做？

在數據查詢時，有時會碰到數據量很大的清單報表。用戶輸入的查詢條件很寬泛，可能會從資料庫中查出幾百上千萬行甚至過億的記錄。如果等著把這些記錄全部檢索出來再生成報表呈現，那需要很長時間，用戶體驗惡劣；而且報表一般採用內存運算機制，大多數情況下也裝不下這麼多數據。所以，我們一般都是使用分頁呈現的方式，盡量快速地呈現出第一頁，然後可以隨意翻頁顯示，每次只顯示一頁，也不會造成內存溢出。

那麼，一般的報表工具或BI系統都是怎麼實現這一機制的呢？

絕大多數產品都是使用資料庫分頁的方法來做的。

具體來講，就是利用資料庫提供的返回指定行號範圍內記錄的語法。界面端根據當前頁號計算出行號範圍（每頁顯示固定行數）作為參數拼入SQL中，資料庫就會只返回當前頁的記錄，從而實現分頁呈現的效果。

這樣做，會有兩個問題：

1. 翻頁時效率較差

用這種辦法呈現出第一頁來一般都會比較快，但如果向後翻頁時，這個原始取數的SQL會被再次執行，並且將前面頁涉及的記錄跳過。有些資料庫沒有OFFSET關鍵字，就只能由界面端自行跳過這些數據（取出後丟棄），像ORACLE還需要用子查詢產生一個序號才能再用序號做過濾，這些動作都會浪費時間，前幾頁還感覺不明顯，但如果翻到的頁號比較大時，就會有等待感了。

2. 可能出現數據不一致

一般來說，每次按頁取數時發出的SQL是獨立的。這樣，如果在兩頁取數之間資料庫又有了插入刪除動作，這時取出來的數據將是最新的，很可能和原來的頁號匹配不上了。比如第1頁取出20行記錄後，在取第2頁前，第1頁的20行記錄中被刪除了1行，那麼這時候取出來的第2頁的第1行就會是原來的第22行記錄，原來的第21行會落到第1頁去了，要再倒翻頁才能看到。如果基於這些數據做匯總統計，那會出現錯誤的結果。

還有一種不常用的方法。向資料庫發出取數SQL生成游標，從中取出一頁後呈現，但並不終止這個游標，要取下一頁的時候再繼續取數。這種方法能克服上述兩個問題，不會發生不一致的現象，但絕大多數的資料庫游標只能向後取數而不是倒回去，這樣在界面上的表現就是只能向後翻頁了，這一點很難向業務用戶解釋，所以很少用這種辦法。

也可以是兩種辦法的結合，向後翻頁時用後一種辦法，一旦發生向前翻頁時，則重新執行取數SQL。這樣比每次分頁取數的體驗略好一些，但並沒有根本上解決問題。

還有什麼好辦法呢？

把取數和呈現做現兩個非同步線程，取數線程發出SQL後就不斷取出數據後緩存到本地存儲中，呈現線程根據頁數計算出行數到本地緩存中去獲取數據顯示。這樣，只要已經取過的數據就能快速呈現，不會有等待感，還沒取到的數據需要等待一下也是正常可理解的；而取數線程只涉及一句SQL，在資料庫中是同一個事務，也不會有不一致的問題。這樣，兩個問題都能得到解決。不過這需要設計一種可以按行號隨機訪問記錄的存儲格式，不然要靠遍歷把記錄數出來，那反應仍然會很遲鈍。

在當前資料庫系統不直接支持這種機制時，只能是報表工具或BI系統受累自己寫這些程序了，對於有大清單報表呈現需求的用戶，就要認真考察這些功能點了。

推薦閱讀：