由于網(wǎng)頁渲染速度的影響，在C/S程序中那種一個Grid包含幾千、上萬行的數(shù)據(jù)基本上在網(wǎng)頁是無法展現(xiàn)的，因此一般采用分頁的形式顯示（也可能采用Visual Srolling方式加載的，企業(yè)應用系統(tǒng)的不是很常見），ASP.NET 的數(shù)據(jù)控件一般帶有分頁功能，3.5以后還提供了單獨的分頁控件，也有用過AspNetPager這個第三方的組件。
分頁的控件實在很方便，以前的處理方式就是數(shù)據(jù)都拿出來，然后由控件進行處理，一般數(shù)據(jù)量不大的時候應該說感覺不出來優(yōu)劣，但由于每次從數(shù)據(jù)庫取的時候都是取所有的數(shù)據(jù)，肯定會增加數(shù)據(jù)庫的壓力，傳輸?shù)臄?shù)據(jù)庫多了對網(wǎng)絡帶寬也會產(chǎn)生壓力的。很有可能查出來1萬條數(shù)據(jù)，最后顯示只用到啟用50條，翻頁的時候又重新去查1萬條數(shù)據(jù)，顯示之后的的又50條。
以下的分頁SQL比較常見的，在SQL Server也有對應的使用TOP關鍵字的版本，記得剛學Oralce的時候就想著怎么不能rownum between minValue and maxValue的用法。與最初的疑惑的原理一樣，rownum是在查詢過程中生成的，因此以下的SQL其實是查出來5300行，然后扔掉了前面5000行，返回后面的300行。當然這種已經(jīng)進了一大步的，由數(shù)據(jù)庫返回的數(shù)據(jù)變少的，只是當查詢的頁數(shù)比較大的時候，查詢還是存在一定的浪費。
- select *
- from (select a.*, rownum as rnum
- from (select * from yz_bingrenyz) a
- where rownum <=5300)
- where rnum >= 5000
|
Linq提供了Skip和Take的API可以用于分頁，由于使用的是Entity Framework，在好奇的驅使下用EFProfiler查看生成的SQL，才知道這樣以下分頁更好。 主要就是使用了row_numer()over()這樣的分析函數(shù)，可以直接找到那第5000行開始的地方，然后在取出30行就行了。
- select *
- from (select *
- from (select t.*,
- row_number() OVER(ORDER BY null) AS "row_number"
- from yz_bingrenyz t) p
- where p."row_number" > 5000
- ) q
- where rownum <= 30
|
比較分析：
本機測試前者耗時1.3s,后者僅0.25s，從以下的執(zhí)行計劃也能看出差異來。
實際應用
如果每次查詢都要寫這種SQL那肯定比較麻煩，可以采用存儲過程進行封裝，但由于要動態(tài)執(zhí)行SQL，效率肯定又要打折扣，所以在ASP.NET中用C#封裝函數(shù)比較好，對于沒有使用實體框架的而用ADO.NET的，傳入表名 、主鍵名、頁數(shù)、要取的行數(shù)作為參數(shù)，用DBCommand進行執(zhí)行返回結果即可。