這是一種非常高效的分頁算法。當數據表中的數據量成百上千萬的時候，上面的這種分頁算法的響應時間是非常短的，通常在幾十毫秒之內。原理很簡單，就是每次分頁，我只取需要的幾十條記錄而已，使用select top也正是基于這樣的考慮。

    上面的兩個分頁算法的例子中，flymorn都使用了時間字段time來進行order by排序，因為在我接觸的絕大多數系統中，我們都需要把用戶最近更新（包括新添加的記錄以及新修改過的老記錄）的內容展示在前面，如果僅僅使用自動編號的id作為排序字段的話，用戶編輯過的老信息將無法展示在前面。這就是flymorn使用時間字段的原因了。

    這里又涉及到聚合索引的問題了。默認情況下，我們是以自動編號id作為主鍵，并且用作聚合索引列，如果上面的算法中，使用這樣的id列來排序的話，效率會更高，數據庫響應的時間會更少；然而，我提到了最近更新的內容需要展示在前面的問題，所以，我們必須使用時間字段來排序。因此，為了更高的分頁效率，我們可以在數據庫設計的時候，把這個時間字段設計為聚合索引列。

    通過這樣的設計后，整個分頁效率就會得到非常高的提高了。

    然而，把這個時間字段作為聚合索引列，存在又一個小問題。因為數據表在排列數據的時候，是按照聚合索引列來進行物理排序的，當用戶添加數據的時候，沒有什么問題，在數據表的末尾添加就行了；當用戶編輯信息的時候，數據庫需要根據這個聚合索引列，把剛編輯過的信息也提到表的末尾，這里就需要耗費一定的時間了。就是說，當我們以時間字段為聚合索引列的時候，我們就需要在 update 數據的時候多耗費一點的時間。

    然而，綜合比較而言，飄易認為，select top的高效分頁算法的關鍵是要避免全表掃描，盡量只獲取需要的字段，排序的字段最好是聚合索引列，實踐表明，以聚合索引列來排序的sql語句的響應時間是最快的。這樣處理之后，對于sql server數據庫來說，即使上千萬的數據量，也不用怕分頁算法失去響應了。

    上面是以 asp 語言為例寫的算法，當然同樣可以改造成其他的如asp.net，php語言所使用。為了更好的使用這樣的分頁代碼，大家也可以把上面的算法改寫成存儲過程。

    最后，留一個小問題：select top分頁的時候，當翻頁到最后的時候，如果排序字段列不是聚合索引列的時候，程序的響應時間會如何呢？