大清單報表應當怎么做？

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

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

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

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

這樣做，會有兩個問題：

1. 翻頁時效率較差

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

2. 可能出現數據不一致

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

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

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

還有什么好辦法呢？

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

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