oracle与WEB分页技术

　　随着Internet技术的发展，Web已越来越多的被应用到各行各业。传统的基于大机或C/S结构的应用也正逐渐的为B/S（Browser/Server）结构所代替。而数据库，作为保存着大量信息的容器，使得WEB应用能够提供更加丰富多彩，及时、个性化的信息。在WEB应用中，我们经常遇到需要从数据库搜索出满足某个特征的数据记录，再显示给特定用户。常常这些满足条件的记录如此之多，一方面在同一个页面显示显得异常臃肿而不切实际，另一方面用户通常也不会对他们都感兴趣，他们似乎更关心按一定规则排序出现在某些开始位置的若干记录。这就要求我们对满足条件的数据进行分页，将用户更关心的记录放在首页，同时给予是否继续浏览（或跳跃式阅读）到指定页甚至最后一页的自由。在这里，我们希望和大家讨论一下使用ORACLE数据库时的WEB分页方法。

　　我们说，一个好的分页方法，它应当满足以下几个要求：

　　1. 数据库处理的数据量最小；
    
　　2. 数据库与WEB应用服务器之间的数据量传输最小；

　　假定我们有如下的业务：行业产品表，10万记录，字段包括产品名称，所在行业，市场价格。要求选择某个行业时，列出该行业下所有产品，并按产品名称排序，超过20条的，按每页20条分页：

     rudolf@TEST902>create table t nologging
       2  as select object_name product_name,mod(object_id,4)*10 category,
       3            object_id price,rpad('a',300,'b') supplier
       4       from all_objects order by 2,1
       5  /

     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  nologging
       3  tablespace indx
       4  /

     Index created.

     rudolf@TEST902>analyze table t compute statistics
       2  for table
       3  for all indexes
       4  for all indexed columns
       5  /

     Table analyzed.

     rudolf@TEST902>select table_name,blocks,empty_blocks from user_tables where table_name = 'T';

     TABLE_NAME                         BLOCKS EMPTY_BLOCKS
     ------------------------------ ---------- ------------
     T                                    1039          113

　　为了便于讨论，我们先来看一下传统的做法:

rudolf@TEST902>select * from
   2   ( select rownum rnm, a.* from
   3     ( select * from t where category = &category_id
   4         order by product_name
   5     ) a
   6  ) where rnm between &minrnm and &maxrnm
   7

　　这里我们使用了三个变量，其中category_id表示用户感兴趣的行业，而minrnm,maxrnm则来模拟web程序控制分页时传入的最小、最大行号。我们希望选出行业为20，属于第289页的所有产品信息。我们猜测上述语句将按以下步骤执行：

　　1. 取出所有满足category=&category_id的记录
    
　　2. 按product_name进行排序
    
　　3. 在排序完毕的结果集中取出第&minrnm到&maxrnm记录之间的数据

rudolf@TEST902>set autot trace
rudolf@TEST902>/
Enter value for category_id: 20
Enter value for minrnm: 4981
Enter value for maxrnm: 5000

20 rows selected.

Execution Plan
----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=436 Card=5263 Bytes=1094704)
    1    0   VIEW (Cost=436 Card=5263 Bytes=1094704)
    2    1     COUNT
    3    2       VIEW (Cost=436 Card=5263 Bytes=1026285)
    4    3         SORT (ORDER BY) (Cost=436 Card=5263 Bytes=1010496)
    5    4           TABLE ACCESS (BY INDEX ROWID) OF 'T' (Cost=284 Card=5263 Bytes=1010496
           )
    6    5             INDEX (RANGE SCAN) OF 'T_CATEGORY_PNAME_IND' (NON-UNIQUE) (Cost=31 C
           ard=5263)

Statistics
----------------------------------------------------------
           0  recursive calls
           0  db block gets
         284  consistent gets
           0  physical reads
           0  redo size
        1829  bytes sent via SQL*Net to client
         514  bytes received via SQL*Net from client
           3  SQL*Net roundtrips to/from client
           1  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 t
   2   where category = &category_id
   3   order by product_name
   4

　　将满足条件的所有记录取到客户端（在这里为WEB应用服务器），然后利用编程语言对结果集分页。以JAVA为例，可以使用ResultSet对象方法absolute直接定位记录而方便地将结果集分页。然而很显然，它甚至满足关于数据库与WEB应用服务器之间的数据量传输最小的要求，很多情况下将明显影响性能，严重时甚至会导致WEB应用服务器一端内存溢出。言归正传，我们开始引入我们的方法。

　　方法一：同分析传统做法类似，我们先列出我们的方法：

     rudolf@TEST902>select * from
       2  ( select rownum rnm, a.* from
       3    ( select * from t where category = &category_id
       4        order by category,product_name
       5    ) a where rownum <= &maxrnm
       6  ) where rnm >= &minrnm
       7

　　与传统做法不同，我们把对最大行号的判断从第三层移到了第二层。改变虽然简单，然而它表达了一个完全不同的执行意图。内部视图：

       select rownum rnm, a.* from
          ( select * from t where category = &category_id
              order by category,product_name
          ) a where rownum <= &maxrnm

　　是8i引入的新操作，在执行计划中，它体现为stopkey。这种操作专门为提取TOP n的需求做了优化。它需要排序字段预先建有索引，由于索引是已排序好的结构，因此取TOP n的问题，就变为从索引中直接从头提取n个索引关键字，然后再根据索引就可快速的找到记录并返回给用户。从而有效避免了检索全部记录的情况。

rudolf@TEST902>set autot trace
rudolf@TEST902>set verify off
Enter value for category_id: 20
Enter value for maxrnm: 20
Enter value for minrnm: 1

20 rows selected.

Execution Plan
----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=284 Card=20 Byte
           s=4160)
    1    0   VIEW (Cost=284 Card=20 Bytes=4160)
    2    1     COUNT (STOPKEY)
    3    2       VIEW (Cost=284 Card=5263 Bytes=1026285)
    4    3         TABLE ACCESS (BY INDEX ROWID) OF 'T' (Cost=284 Card=
           5263 Bytes=1010496)
    5    4           INDEX (RANGE SCAN) OF 'T_CATEGORY_PNAME_IND' (NON-
           UNIQUE) (Cost=31 Card=5263)

Statistics
----------------------------------------------------------
           0  recursive calls
           0  db block gets
           7  consistent gets
           0  physical reads
           0  redo size
        1848  bytes sent via SQL*Net to client
         514  bytes received via SQL*Net from client
           3  SQL*Net roundtrips to/from client
           0  sorts (memory)
           0  sorts (disk)
          20  rows processed

　　应将count(stopkey)操作与table access(by index rowid)结合起来看，这样一来，table access(by index rowid)实际上只处理了&maxrnm条记录，这里为20条。它的执行计划可以解释为：

     rnm := 1;
     for rec in (select * from t where category = &category_id order by category, product_name)
     loop
       rnm := rnm + 1;
       if rnm > [$maxrnm then exit loop] end if;
       fetch rec;
     end loop;
     filter rec where rownum < [$minrnm]

　　与传统方法相比，它大大减小了数据库处理的压力：284个一致读减小为7个，性能因此得到了改善。然而也许你注意到了，当用户不停的向后翻页，使得&maxrnm逐渐接近满足条件的记录数时，它的性能

　　也渐渐降低到与传统方法相近的水平：

rudolf@TEST902>set autot trace statistics
rudolf@TEST902>select * from
   2   ( select rownum rnm, a.* from
   3     ( select * from t where category = &category_id
   4         order by category,product_name
   5     ) a where rownum <= &maxrnm
   6   ) where rnm >= &minrnm
   7  /
Enter value for category_id: 20
Enter value for maxrnm: 5000
Enter value for minrnm: 4981

20 rows selected.

Statistics
----------------------------------------------------------
           0  recursive calls
           0  db block gets
         275  consistent gets
           0  physical reads
           0  redo size
        1829  bytes sent via SQL*Net to client
         514  bytes received via SQL*Net from client
           3  SQL*Net roundtrips to/from client
           0  sorts (memory)
           0  sorts (disk)
          20  rows processed

rudolf@TEST902>

　　我们看到，当用户浏览到第249页时，这种方法共使用了275个一致读，与传统方法的284个一致读已很接近了。幸运的是，在很多应用中，98%的用户将只关心前5页的数据，使得这些应用仍能得益于这个方法。当我们把order by子句改为order by ... desc，同时创建逆索引，我们甚至可以把某些用户关心最后5页数据的需求改变为关心前5页。尽管如此，还是有某些应用，用户浏览页面更可能是随机的，这时我们就可以用到第二种方法：

　　方法二：

rudolf@TEST902>select * from t
   2        where rowid in
   3        ( select rid from
   4            ( select rownum rno,rowid rid from
   5                ( select rowid from t
   6                  where category = &category_id
   7                  order by category,product_name
   8                ) where rownum <= &maxrnm
   9            ) where rno >= &minrnm
  10        )
  11

　　在这一方法中，我们考虑到索引与表相比，身材上大大小于后者（我们可以把它看作一个小表），因此我们试图先在索引中搜索出某页记录的物理位置，然后根据这些物理位置（rowid）在表中直接取出相应的记录，我们认为它将消除前一种方法中index range scan所有满足条件记录时带来的高成本（到某一刻CBO甚至认为它高于FULL TABLE SCAN而选择FULL TABLE SCAN）。

Enter value for category_id: 20
Enter value for maxrnm: 5000
Enter value for minrnm: 4981

20 rows selected.

Execution Plan
----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=5054 Card=5000 Bytes=1095000)
    1    0   NESTED LOOPS (Cost=5054 Card=5000 Bytes=1095000)
    2    1     VIEW (Cost=31 Card=5000 Bytes=100000)
    3    2       SORT (UNIQUE)
    4    3         COUNT (STOPKEY)
    5    4           VIEW (Cost=31 Card=5263 Bytes=36841)
    6    5             INDEX (RANGE SCAN) OF 'T_CATEGORY_PNAME_IND' (NON-UNIQUE) (Cost=31 C
           ard=5263 Bytes=178942)

    7    1     TABLE ACCESS (BY USER ROWID) OF 'T' (Cost=1 Card=1 Bytes=199)

Statistics
----------------------------------------------------------
           0  recursive calls
           0  db block gets
          50  consistent gets
           0  physical reads
           0  redo size
        1551  bytes sent via SQL*Net to client
         503  bytes received via SQL*Net from client
           2  SQL*Net roundtrips to/from client
           1  sorts (memory)
           0  sorts (disk)
          20  rows processed

　　我们可以看到语句的执行逻辑：

     rnm := 1;
     for rec in (select * from t_category_pname_ind
                   where category = &category_id order by category, product_name)
     loop
       rnm := rnm + 1;
       if rnm > [$maxrnm then exit loop] end if;
       fetch rowid;
     end loop;
     filter rowid array where rownum < [$minrnm]
     select * from t where rowid in ( rowid array );

　　基本上，无论用户浏览哪页，数据库的数据处理量都较为相近，约为index fast full scan的成本加上20次access by rowid的成本。与前一种方法相比，当用户只浏览前几页时，可能它的成本相对稍大，然而随着用户逐页往后浏览，它的成本优势也迅速的显现出来。同样浏览第4981-5000条记录，我们看到方法一产生了275个一致读，而本方法仅仅产生了50个。对于我们“数据库处理量最小”的要求而言，可说是大大迈进了一步。

　　综上所述，由于用户浏览特点、习惯不同，我们可以采用不同的分页方法，以便更有效的利用资源。

　　我接触过的最厉害的是Ebay的系统，他们的浏览量太大，以至于使用数据库来做这种排序的功能，系统无法负担。

　　结果他们采用的是直接在WebServer上面进行排序。

　　还有一个思路，就是如果访问量实在很大，可以根据类别，把不同的列别干脆放到不同的表的里面，这样，每个表的物理大小大大减小，每次的读取，都会大大减少，从而降低数据库服务器的压力，提高相应时间。

　　如果页面的访问量非常大，但是更新非常小的话，还可以采用另外一个技术，一个表对应就是多个表，同样的内容，冗余到不同的表的里面，每个表都采用IOT技术（Index Organized Table)，原来的主键 ＋ 需要排序的字段，这样，每次按照不同的排序方法，都可以非常迅速的得到需要的答案。但是这个需要应用程序写的稍微复杂一点、

　　对于数据仓库系统.可以使用分析函数来进行一些简化处理,在以后将给大家介绍

查看本文来源