文章內(nèi)容

海量數(shù)據(jù)高性能分頁新方法

發(fā)布時(shí)間: 2012/8/2 18:13:45

海量數(shù)據(jù)高性能分頁新方法
最近，一直在進(jìn)行項(xiàng)目性能的優(yōu)化工作，從中也有一些心得體會(huì)，拙見僅供大家參考，歡迎探討交流！
    對(duì)于數(shù)據(jù)庫分頁的做法，從網(wǎng)上的資料綜合來看，大體分為三類：
    1。根據(jù)ID分頁
    2。使用Top分頁
    3。利用Not In分頁-

    這三種方法中，速度最快的是第一種，第二種其次，第三種是最慢的。第一種方法雖然最快，但是，在實(shí)際的應(yīng)用中，其實(shí)并不多。因?yàn)�，基本上沒有頁面會(huì)根據(jù)ID來排序，通常都是根據(jù)某（幾）個(gè)有意義的字段來排序。第二種方法是我平常用的最多的，Top的效率還是不錯(cuò)的。第三種方法，由于會(huì)引起全表掃描，所以，一般不怎么推薦使用。在這里，第二和第三種方法都有一個(gè)缺點(diǎn)，就是隨著頁數(shù)的增多，越是靠后的數(shù)據(jù)，獲取越慢。
    所以，我在思考，有沒有一種比Top更快的方法呢？現(xiàn)知的就只有按照ID分頁了，但是，我的數(shù)據(jù)中沒有ID字段，那么我可以做一個(gè)變通，把要排序的（一個(gè)或多個(gè)）字段組合成一個(gè)相當(dāng)于ID功效的東西來看待，然后，對(duì)這個(gè)組合字段排序。我的表達(dá)可能不是很清楚，那么我們舉個(gè)例子吧。
    現(xiàn)有一表：工廠物料表，數(shù)據(jù)量60萬
    TblOrgItem
    (
        OID nvarchar(40),--自動(dòng)產(chǎn)生的GRID
        OrgCode nvarchar(50),--工廠代碼
        OrgName nvarchar(50),--工廠名稱
        ItemNo nvarchar(50),--物料編碼
        ItemName nvarchar(50),--物料名稱
        ......
    )
    需求：按照先"工廠代碼"升序，再"物料編碼"升序的順序排序顯示
    那么這個(gè)時(shí)候我們可以把"工廠代碼"+"物料編碼"的組合看作是一個(gè)主鍵，然后對(duì)它進(jìn)行分頁。在這里，我們需要這么幾個(gè)參數(shù)：
    傳入?yún)?shù)：
    @PageSize int,
    @PageIndex int,
    @LastOrgCode nvarchar(50),--上一頁最后一條記錄的工廠代碼
    @LastItemNo nvarchar(50),--上一頁最后一條記錄的物料編碼
    組合起來的分頁SQL應(yīng)該就是這樣的了，我直接寫了，實(shí)際執(zhí)行的時(shí)候要拼湊成字符串動(dòng)態(tài)執(zhí)行：
    select top @PagaSize OrgCode,OrgName,ItemNo,ItemName from TblOrgItem
                where OrgCode>=@LastOrgCode and ItemNo>@LastItemNo --如果是第一頁，可以不用這一行
                Order by OrgCode,ItemNo
    注：對(duì)于組合字段大于2個(gè)及2個(gè)以上的，Where 條件的寫法是：前面的字段都是用">="判斷，只有最后一個(gè)字段使用">"判斷。
    這個(gè)分頁SQL執(zhí)行的效率應(yīng)該比較接近用ID進(jìn)行分頁的效率了，如果，再在這個(gè)表的OrgCode,ItemNo字段上加上聚集索引的話，分頁的效果又會(huì)更上一層樓了！