這是一種非常高效的分頁(yè)算法。當(dāng)數(shù)據(jù)表中的數(shù)據(jù)量成百上千萬(wàn)的時(shí)候，上面的這種分頁(yè)算法的響應(yīng)時(shí)間是非常短的，通常在幾十毫秒之內(nèi)。原理很簡(jiǎn)單，就是每次分頁(yè)，我只取需要的幾十條記錄而已，使用select top也正是基于這樣的考慮。

    上面的兩個(gè)分頁(yè)算法的例子中，flymorn都使用了時(shí)間字段time來(lái)進(jìn)行order by排序，因?yàn)樵谖医佑|的絕大多數(shù)系統(tǒng)中，我們都需要把用戶最近更新（包括新添加的記錄以及新修改過的老記錄）的內(nèi)容展示在前面，如果僅僅使用自動(dòng)編號(hào)的id作為排序字段的話，用戶編輯過的老信息將無(wú)法展示在前面。這就是flymorn使用時(shí)間字段的原因了。

    這里又涉及到聚合索引的問題了。默認(rèn)情況下，我們是以自動(dòng)編號(hào)id作為主鍵，并且用作聚合索引列，如果上面的算法中，使用這樣的id列來(lái)排序的話，效率會(huì)更高，數(shù)據(jù)庫(kù)響應(yīng)的時(shí)間會(huì)更少；然而，我提到了最近更新的內(nèi)容需要展示在前面的問題，所以，我們必須使用時(shí)間字段來(lái)排序。因此，為了更高的分頁(yè)效率，我們可以在數(shù)據(jù)庫(kù)設(shè)計(jì)的時(shí)候，把這個(gè)時(shí)間字段設(shè)計(jì)為聚合索引列。

    通過這樣的設(shè)計(jì)后，整個(gè)分頁(yè)效率就會(huì)得到非常高的提高了。

    然而，把這個(gè)時(shí)間字段作為聚合索引列，存在又一個(gè)小問題。因?yàn)閿?shù)據(jù)表在排列數(shù)據(jù)的時(shí)候，是按照聚合索引列來(lái)進(jìn)行物理排序的，當(dāng)用戶添加數(shù)據(jù)的時(shí)候，沒有什么問題，在數(shù)據(jù)表的末尾添加就行了；當(dāng)用戶編輯信息的時(shí)候，數(shù)據(jù)庫(kù)需要根據(jù)這個(gè)聚合索引列，把剛編輯過的信息也提到表的末尾，這里就需要耗費(fèi)一定的時(shí)間了。就是說(shuō)，當(dāng)我們以時(shí)間字段為聚合索引列的時(shí)候，我們就需要在 update 數(shù)據(jù)的時(shí)候多耗費(fèi)一點(diǎn)的時(shí)間。

    然而，綜合比較而言，飄易認(rèn)為，select top的高效分頁(yè)算法的關(guān)鍵是要避免全表掃描，盡量只獲取需要的字段，排序的字段最好是聚合索引列，實(shí)踐表明，以聚合索引列來(lái)排序的sql語(yǔ)句的響應(yīng)時(shí)間是最快的。這樣處理之后，對(duì)于sql server數(shù)據(jù)庫(kù)來(lái)說(shuō)，即使上千萬(wàn)的數(shù)據(jù)量，也不用怕分頁(yè)算法失去響應(yīng)了。

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

    最后，留一個(gè)小問題：select top分頁(yè)的時(shí)候，當(dāng)翻頁(yè)到最后的時(shí)候，如果排序字段列不是聚合索引列的時(shí)候，程序的響應(yīng)時(shí)間會(huì)如何呢？