分頁演算法，是Web開發人員很關心的一個問題，幾乎每個資料庫相關的應用程式都要涉及到分頁演算法，有很多人寫過這方面的文檔，似乎沒有什麼好討論的了；但實際上換一種數據的表現形式，就可以採用更好的分頁演算法，那我們現在就看看還能不能做得更好。
先說說已有的一些方法。
一是透過DataGrid 分頁，這種方式最簡單，但效率不高，需要讀取所需資料前面的所有資料。
二是透過指定起始記錄和記錄數的DbDataAdapter.Fill 來填入DataSet 的分頁方式，這種方式也簡單，但同樣效率不高，也需要讀取所需資料前面的所有資料。
第三是透過多個select top 和多次排序，從表格的中間選取所需的記錄；為了使相鄰頁的資料不重複，需要使用not in，會導致在選擇大資料量的表格的尾部資料時，資料庫的效能會有很大的降低。
假設我們換一種表格的展現形式，就以傳統的C/S 應用下的帶有捲軸的Grid 展現方式為例；其實這種方式才是資料庫表格最適合的展現方式，而Web 應用下常用的1,2,3....的頁碼連接方式或上一頁、下一頁按鈕的頁碼瀏覽條方式，都是不得已而為之，因為不能通過簡單的技術，在Web 應用下實現帶滾動條的Grid。
資料庫的表格都是帶有主鍵的，以區分錶格中不同的記錄；用戶界面上的Grid 裡的數據從邏輯上也是有主鍵的，否則數據會有歧義，但大多數的應用，沒有設置，也無法知道所讀出資料的主鍵；即使少數應用設定了，也知道所讀資料的主鍵，但並沒有將其應用到分頁中；其實只要知道了所讀資料的主鍵，就可以非常容易的進行分頁。
首頁的演算法很簡單
select top 頁大小* from 表名order by 主鍵
對於帶有捲軸的表格，資料是一頁一頁順序滾動，即使拖動滾動條，也可以一頁頁滾動到所選的位置，當拖動到一個新頁時的演算法為
select top 頁大小* from 表名where 主鍵> 上一頁末記錄的主鍵order by 主鍵
如果採用了緩存的方式，所有的資料都只需要下載一次，只有滾動到尾部時，才下載新的資料。
這種演算法要求知道Grid 中資料的主鍵，並將主鍵的資料套用到分頁；對於多主鍵和排序的表格，演算法是一樣的，只是語句複雜了一些。不但可以從首頁開始，也可以從末頁開始，向前翻滾。
這個演算法的效能沒有問題，對於不論多大的表，選擇那個位置的記錄都是一樣的，比較適合於用首頁、上一頁、下一頁和末頁的分頁選擇方式，更適合於帶滾動條的Grid ；不適合指定頁碼的分頁。
採用此演算法的帶有捲軸的Grid 可以參考我們的示範www.BizStruct.cn 。
請在提出問題時，先考慮兩點，否則可能認識不到這個演算法和我們系統結合的優點：
第一：傳統的C/S 應用程式的表格和Web上的分頁表格，誰比較方便。
第一，我們實現的帶有捲軸的表格，和傳統的C/S 應用的表格的差別有多大。
回應的解釋：
有的回覆提出無法實現「跳到xx頁」這樣的操作。
但我們想想，在C/S 的應用程式環境下，如果誰用這種頁面跳轉的方式，大家一定會覺得怪異。
而我們實作的有捲軸的Grid 在區域網路環境下，速度幾乎和以前的C/S 應用程式差不多，在廣域網路的情況下，速度也很快。
Web 應用的「跳到XX頁的動作」其實是不得已而為之，如果能實現傳統的C/S 應用程式的Grid，為什麼還要用這個呢？