對大量數據的分頁處理
問題描述：
背景1：一客戶通過IE請求Web服務器查詢數據，而查詢結果是上千條甚至是上萬條記錄，要求查詢結果傳送到IE客戶端並分頁顯示。
背景2：一客戶通過IE或者其他方式請求Web服務器查詢數據，而查詢結果是上千條甚至是上萬條記錄，並要求查詢結果把包傳送到客戶的E-mail中。
問：對於這樣的有大量數據的結果集，在Web服務器端如何有效的處理？
可能涉及到的問題：
1． 內存佔用
大量數據的結果集，可能要
2． 傳輸速度及策略
具體的分頁處理技術
序號 名稱 處理方法 針對的數據庫 例子說明 備註
1 遊標查詢 直接使用ResultSet來處理。ResultSet是直接在數據庫上建立遊標，然後通過ResultSet的行位置定位接口來獲得指定行位置的記錄。
當用戶第一請求數據查詢時，就執行SQL語句查詢，獲得的ResultSet對象及其要使用的連接對象都保存到其對應的會話對象中。
以後的分頁查詢都通過第一次執行SQL獲得的ResultSet對象定位取得指定行位置的記錄。
最後在用戶不再進行分頁查詢時或會話關閉時，釋放數據庫連接和ResultSet對象等數據庫訪問資源。
說明：在用例分頁查詢的整個會話期間，一個用戶的分頁查詢就要佔用一個數據庫連接對象和結果集的遊標，這種方式對數據庫的訪問資源佔用比較大，並且其利用率不是很高。 所有的數據庫產品。 優點：
減少了數據庫連接對象的多次分配獲取，減少了對數據庫的SQL查詢執行。
缺點：
佔用數據庫訪問資源－數據庫連接對象，並佔用了數據庫上的資源－遊標。而這些資源都是十分寶貴的有限制的。
結論：
這種的數據庫查詢分頁處理方式不是最佳的。一般不適用這種方式。
2 定位行集SQL查詢 主要是直接使用數據庫產品的提供的對查詢的結果集可定位行範圍的SQL接口技術。
在用戶的分頁面查詢請求中，每次可取得查詢請求的行範圍的參數，然後使用這些參數生產取得指定行範圍的的SQL查詢語句，然後每次請求獲得一個數據庫連接對象並執行SQL查詢，把查詢的結果返回給用戶，最後釋放說有的數據庫訪問資源。
說明：這種方式需要每次請求時都要執行數據庫的SQL查詢語句；對數據庫的訪問資源是使用完就立即釋放，不白白佔用數據庫訪問資源。 對特定（提供了對查詢結果集可定位功能的）的數據庫產品。
如：Oracle,DB2, PostgreSQL,mySQL等。(MS SQL Server 沒有提供此技術。) 如:
1． Oracle數據庫使用關鍵字：rowid或rownum
2． DB2:
rowid或rownum ()
3． PostgreSQL 使用LIMIT 和 OFFSET
4． MySQL 使用Limit 優點：
這種技術是直接使用數據庫產品自己提供的可對查詢結果集定位行範圍過濾的功能，因此直接利用了數據庫的性能對此分頁查詢的優化功能。
對數據庫的訪問資源（數據庫連接對象，數據庫遊標等）沒有浪費，這些資源的充分重複的利用。
對查詢的結果對Web容器沒有什麼特別要求。
缺點：
要執行多次數據庫SQL查詢操作。對每次的分頁面操作請求都要指定相應範圍的結果集來執行SQL語句的數據庫查詢操作，這對數據庫有一定的影響。
對每次分頁面查詢請求要頻繁的從Web容器中獲得數據庫訪問資源（數據庫連接對象和數據庫遊標）。
要依賴於具體的數據庫產品。因爲對沒有實現沒有提供此技術的數據庫產品不能使用此方式。
結論：
由於每次對數據庫的SQL查詢操作相對而言耗用的數據資源比較少，並且在實際用戶的操作中，有可能用戶對查詢的所有結果集只是需要查看其中的部分頁面。
因此這種方式是最佳的。
3/ 特別處理的定位行集SQL查詢 這種方式是在方式2的基礎上針對不提供對查詢結果集行範圍定位的數據庫產品。
其在Web容器端的操作邏輯大致和方式2相同。
只是先要對要查詢的數據庫表要有一字段的數據能區別每條不同的數據記錄。第一次查詢時，獲得用來可唯一標識不同記錄的字段的所有結果集，並緩存起來以備後面的分頁面查詢指定要查詢的結果集的行範圍。 主要是針對不同對查詢行集可定位範圍獲得的數據庫產品，如MS SQL Server等。 假設從A，B，C三個表中選取數據。且A有字段ID用來可唯一區別不同的記錄。
那麼第一次查詢的時候，會查詢兩次1. select A.id from A,B,C where condition.
2. 把A的ID緩存到SESSION中⾿3.從Session中。現可按照次序來取得相應頁面範圍的ID來，並構造下一個查詢語句：select A.name, B.add from A,B,C where condition && (
A.ID in 本頁面範圍的 ID )
以後每次翻頁的時候，依次獲得對應頁的ID只要表中唯一的就可以了。無所謂大小，順序⾿這樣，SESSSION緩存的就只是一列而不是所有列了。當然，對於列數不多的，效果並不好。
也可使用存儲過程實現，可參照：http://expert.csdn.net/Expert/topic
/2365/2365596.xml?temp=.7529261
優點：
同方式2
缺點：
同方式2；
還要在要查詢的數據庫表中建立一個相應的ID,用來唯一區別每條記錄。
結論：
同方式2。
緩存一次SQL查詢的結果集 優點：
缺點：
既然我們要緩存結果，那麼用戶就可能會看到過期的數據
說明：對於實際情況的應用來說，一般結合實際情況，結合使用方式2（或方式3）和方式4。如：一個應用場景：對公司的產品的查詢是經常的，但是產品的種類不是很多，這時可使用緩存方式；但是對有些查詢結果集較大，數據庫和Web容器之間的網絡訪問由可能是遠程的，這時候可考慮使方式2（或者方式3）。