大資料分頁解決方案，資料分頁解決方案

大資料分頁解決方案，資料分頁解決方案

1 編寫目的
 解決系統需要檢索大資料列表時的效能問題，而提出的分頁方案
2 術語、定義和縮減語
   

3 大資料量檢索的效能問題分析
大資料量檢索的效能存在問題，問題主要包括

3.1 用戶端在IE或者cs端資料量過大會導致IE變慢，甚至死結
現象：
  IE瀏覽器崩潰
  瀏覽器白板，停止回應

3.2 用戶端--web伺服器之間的資料轉送量大會導致用戶端速度變慢，效率降低
現象：
IE瀏覽器長期在等待時白板
IE 瀏覽器操作慢

3.3 中介層構造大資料列表會導致中介層效能降低
現象：
並發訪問多時，應用伺服器和資料庫伺服器cpu佔有量過大
導致系統效能降低

3.4 資料庫sql一次選取大資料量會導致資料庫效能降低
3.4.1 如果一次查詢返回資料過多會影響效能
3.4.2 如果檢索條件繁瑣也會影響效能
現象：
並發訪問多時，資料庫伺服器負載大cpu佔有量過大
資料庫伺服器和應用伺服器通訊會造成瓶頸

4 方案論證
4.1 傳統解決方案候選方案- web服務端分頁
在web服務端實現分頁，根據使用者選擇的頁數，選取指定的資料返回到用戶端
  優點：開發簡單
  優點：解決了web端和用戶端資料傳遞的問題
  缺點：不能解決中介層和資料庫的效能

4.2 最佳化解決方案(1)-資料庫分頁
根據使用者當前選擇的頁數，每次從資料庫選取這些資料，比如每頁100條，選第二頁的時候就只查詢第200條到300條的資料。
 
1) 設計分析。
優點：可以解決除3.4.2外的所有效能問題
 缺點：每次查詢要用rownum構造子查詢選取指定資料
 缺點：Oracle 和 Sqlserver2005都支援，但之前的sqlserver版本只支援Top
 缺點：大資料量如果檢索條件效能低的話,不能解決1.4.2的效能問題
 缺點：開發稍微複雜，但是可以通過封裝解決
4.3 最佳化解決方案(2)-所見即所取的虛模式資料庫分頁（）
第一次查詢返回第一頁的列表資料，然後非同步擷取一定數量級的serial_id到用戶端，客戶選擇頁數的時候把此頁的serial_id傳遞到伺服器構造 id=001 or id = 002 or id = 003 的查詢，返回列表資料。。
 
1設計問題。
優點：可以解決所有的大資料量的效能問題。
這樣做主要是解決檢索條件繁瑣的效能問題，主要情境就是檢索效能低的時候，只有第一頁速度慢，然後每頁速度都很快（因為是通過主鍵檢索）
優點：不使用資料庫特性，任何資料庫都支援
缺點：開發複雜，但是可以通過封裝解決

4.4 其他提高效能的方法

a) 大部分使用者都是只看第一頁資料，首次選取只選取前pagesize條資料。點每個頁碼的時候再試用分頁方案
b) 系統bs端沒有優秀的清單控制項，還沒能實現顯示列的自定製，實現了顯示列的自定製，可以在db端只選取指定列的資料。
c) 也可以不用分頁的模式，用虛模式的捲軸列表來瀏覽資料，實際的展示效果比分頁模式好

參考： (1)

在ORACLE大資料量下的分頁解決方案?

打資料量的話，其實是查詢的效率問題了。一般的索引、欄位最佳化都沒想過的話，考慮拆表、分區，如果是匯總型資料的話，那麼可以對查詢的資料進行前期匯總若干次之後在進行查詢。
 
大資料量查詢並分頁顯示問題

對於大量的資料 分頁的時候，我們可以按需取資料。
行得到記錄 總數 ， Rscount,
然後 根據自己需要設定的每頁顯示的記錄條數， 如 12條
再計算 可以分成多少頁 Pagecount= Rscount/12

如果是第5頁， 則取第6頁的12條記錄，頁碼是可以用變數的，如PageSize 每次給不同的頁值。
select top 12 * from 表 where Id not in(select top 5*12 Id from 表 order by id desc) order by Id desc

以此類推和 擴充。

20萬條記錄的資料庫 用access 太可憐了！