隨著Internet技術的發展，Web已越來越多的被應用到各行各業。傳統的基于大機或C/S結構的應用也正逐漸的為B/S（Browser/Server）結構所代替。而數據庫，作為保存著大量信息的容器，使得Web應用能夠提供更加豐富多彩，及時、個性化的信息。在Web應用中，我們經常碰到需要從數據庫搜索出滿足某個特征的數據記錄，再顯示給特定用戶。經常這些滿足條件的記錄如此之多，一方面在同一個頁面顯示顯得異常臃腫而不切實際，另一方面用戶通常也不會對他們都感愛好，他們似乎更關心按一定規則排序出現在某些開始位置的若干記錄。這就要求我們對滿足條件的數據進行分頁，將用戶更關心的記錄放在首頁，同時給予是否繼續瀏覽（或跳躍式閱讀）到指定頁甚至最后一頁的自由。在這里，我們希望和大家討論一下使用Oracle數據庫時的Web分頁方法。 我們說，一個好的分頁方法，它應當滿足以下幾個要求： 1. 數據庫處理的數據量最小； 2. 數據庫與Web應用服務器之間的數據量傳輸最小。 假定我們有如下的業務：行業產品表，10萬記錄，字段包括產品名稱，所在行業，市場價格。要求選擇某個行業時，列出該行業下所有產品，并按產品名稱排序，超過20條的，按每頁20條分頁： rudolf@TEST902>create table t nologging2　as select object_name prodUCt_name,mod(object_id,4)*10 category,3object_id price,rpad('a',300,'b') supplier4　 from all_objects order by 2,15　/Table created.rudolf@TEST902>select count(*) from t;COUNT(*)----------21110用以上語句，我們快速生成了一個行業產品表，其中all_objects為Oracle的一個系統表（我們經常可以使用類似的方法生成測試數據）。接下來，我們創建了索引，并為使用CBO分析了表，分析顯示該表共用去1039個數據塊： rudolf@TEST902>create index t_category_pname_ind on t (category,product_name)2　nologging3　tablespace indx4　/Index created.rudolf@TEST902>analyze table t compute statistics2　for table3　for all indexes4　for all indexed columns5　/Table analyzed.rudolf@TEST902>select table_name,blocks, empty_blocks from user_tables where table_name = 'T';TABLE_NAME BLOCKS EMPTY_BLOCKS------------------------------ ---------- ------------T1039　113為了便于討論，我們先來看一下傳統的做法: rudolf@TEST902>select * from2　 ( select rownum rnm, a.* from3 ( select * from t where category = &category_id4 order by product_name5 ) a6　) where rnm between &minrnm and &maxrnm7這里我們使用了三個變量，其中category_id表示用戶感愛好的行業，而minrnm,maxrnm則來模擬Web程序控制分頁時傳入的最小、最大行號。我們希望選出行業為20，屬于第289頁的所有產品信息。我們猜測上述語句將按以下步驟執行： 1. 取出所有滿足category=&category_id的記錄； 2. 按product_name進行排序； 3. 在排序完畢的結果集中取出第&minrnm到&maxrnm記錄之間的數據。 rudolf@TEST902>set autot tracerudolf@TEST902>/Enter value for category_id: 20Enter value for minrnm: 4981Enter value for maxrnm: 500020 rows selected.Execution Plan0　SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=436 Card=5263 Bytes=1094704)10　 VIEW (Cost=436 Card=5263 Bytes=1094704)21 COUNT32　 VIEW (Cost=436 Card=5263 Bytes=1026285)43 SORT (ORDER BY) (Cost=436 Card=5263 Bytes=1010496)54　 TABLE Access (BY INDEX ROWID) OF 'T' (Cost=284 Card=5263 Bytes=1010496)65 INDEX (RANGE SCAN) OF 'T_CATEGORY_PNAME_IND' (NON-UNIQUE) (Cost=31 Card=5263)Statistics0　recursive calls0　db block gets284　consistent gets0　physical reads0　redo size1829　bytes sent via SQL*Net to client514　bytes received via SQL*Net from client3　SQL*Net roundtrips to/from client1　sorts (memory)0　sorts (disk)20　rows processed我們可以根據執行計劃第二列的數字來閱讀計劃，即數字大的最先執行，如“5 index (range scan)”，數字相等時，按從上到下的順序執行。上述執行計劃顯示了與我們估計相同的順序，我們看到滿足where條件的記錄一共5263條左右（第4步中的 card=5263），它們全部被取出，并參與排序（第3步），并在將結果集返回給用戶前，一直在處理所有的5263條記錄。然而事實上用戶似乎只關心本頁即20條記錄。顯然它與我們關于數據庫處理量最小的要求相距甚遠。在分析部分，284個一致讀進一步說明數據庫處理了所有滿足條件的記錄（整個表占1039個數據塊，共4個擁有相近產品數的行業，則每個行業約占259個數據塊）。 現在，我們把上述語句換成： rudolf@TEST902>select * from t2　 where category = &category_id3　 order by product_name4　將滿足條件的所有記錄取到客戶端（在這里為Web應用服務器），然后利用編程語言對結果集分頁。以Java為例，可以使用ResultSet對象方法absolute直接定位記錄而方便地將結果集分頁。然而很顯然，它甚至滿足關于數據庫與Web應用服務器之間的數據量傳輸最小的要求，很多情況下將明顯影響性能，嚴重時甚至會導致Web應用服務器一端內存溢出。言歸正傳，我們開始引入我們的方法。 方法一：同分析傳統做法類似，我們先列出我們的方法： rudolf@TEST902>select * from2　( select rownum rnm, a.* from3( select * from t where category = &category_id4order by category,product_name5) a where rownum <= &maxrnm6　) where rnm >= &minrnm7與傳統做法不同，我們把對最大行號的判定從第三層移到了第二層。改變雖然簡單，然而它表達了一個完全不同的執行意圖。內部視圖： select rownum rnm, a.* from( select * from t where category = &category_idorder by category,product_name) a where rownum <= &maxrnm是8i引入的新操作，在執行計劃中，它體現為stopkey。這種操作專門為提取TOP n的需求做了優化。它需要排序字段預先建有索引，由于索引是已排序好的結構，因此取TOP n的問題，就變為從索引中直接從頭提取n個索引要害字，然后再根據索引就可快速的找到記錄并返回給用戶。從而有效避免了檢索全部記錄的情況。 rudolf@TEST902>set autot tracerudolf@TEST902>set verify offEnter value for category_id: 20Enter value for maxrnm: 20Enter value for minrnm: 120 rows selected.Execution Plan0　SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=284 Card=20 Bytes=4160)10　 VIEW (Cost=284 Card=20 Bytes=4160)21 COUNT (STOPKEY)32　 VIEW (Cost=284 Card=5263 Bytes=1026285)43 TABLE ACCESS (BY INDEX ROWID) OF 'T' (Cost=284 Card=5263 Bytes=1010496)54　 INDEX (RANGE SCAN) OF 'T_CATEGORY_PNAME_IND' (NON-UNIQUE) (Cost=31 Card=5263)Statistics0　recursive calls0　db block gets7　consistent gets0　physical reads0　redo size1848　bytes sent via SQL*Net to client514　bytes received via SQL*Net from client3　SQL*Net roundtrips to/from client0　sorts (memory)0　sorts (disk)20　rows processed應將count(stopkey)操作與table access(by index rowid)結合起來看，這樣一來，table access(by index rowid)實際上只處理了&maxrnm條記錄，這里為20條。