今天没事偷着乐,转贴一文慢慢细读,看看能理解多少^__^!
原文出处:http://www.cnoug.org/viewthread.php?tid=38&highlight=%B7%D6%D2%B3
随着Internet技术的发展,Web已越来越多的被应用到各行各业。传统的基于大机或C/S结构的应用也正逐渐的为B/S(Browser/Server)结构所代替。而数据库,作为保存着大量信息的容器,使得WEB应用能够提供更加丰富多彩,及时、个性化的信息。在WEB应用中,我们经常遇到需要从数据库搜索出满足某个特征的数据记录,再显示给特定用户。常常这些满足条件的记录如此之多,一方面在同一个页面显示显得异常臃肿而不切实际,另一方面用户通常也不会对他们都感兴趣,他们似乎更关心按一定规则排序出现在某些开始位置的若干记录。这就要求我们对满足条件的数据进行分页,将用户更关心的记录放在首页,同时给予是否继续浏览(或跳跃式阅读)到指定页甚至最后一页的*。在这里,我们希望和大家讨论一下使用ORACLE数据库时的WEB分页方法。
我们说,一个好的分页方法,它应当满足以下几个要求:
1. 数据库处理的数据量最小;
2. 数据库与WEB应用服务器之间的数据量传输最小;
假定我们有如下的业务:行业产品表,10万记录,字段包括产品名称,所在行业,市场价格。要求选择某个行业时,列出该行业下所有产品,并按产品名称排序,超过20条的,按每页20条分页:
create">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.
select">rudolf@TEST902>select count(*) from t;
COUNT(*)
----------
21110
用以上语句,我们快速生成了一个行业产品表,其中all_objects为oracle的一个系统表(我们常常可以使用类似的方法生成测试数据)。接下来,我们创建了索引,并为使用CBO分析了表,分析显示该表共用去1039个数据块:
create">rudolf@TEST902>create index t_category_pname_ind on t (category,product_name)
2 nologging
3 tablespace indx
4 /
Index created.
analyze">rudolf@TEST902>analyze table t compute statistics
2 for table
3 for all indexes
4 for all indexed columns
5 /
Table analyzed.
select">rudolf@TEST902>select table_name,blocks,empty_blocks from user_tables where table_name = 'T';
TABLE_NAME BLOCKS EMPTY_BLOCKS
------------------------------ ---------- ------------
T 1039 113
为了便于讨论,我们先来看一下传统的做法:
select">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记录之间的数据
set">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个数据块)。
现在,我们把上述语句换成:
select">rudolf@TEST902>select * from t
2 where category = &category_id
3 order by product_name
4
将满足条件的所有记录取到客户端(在这里为WEB应用服务器),然后利用编程语言对结果集分页。以JAVA为例,可以使用ResultSet对象方法absolute直接定位记录而方便地将结果集分页。然而很显然,它甚至满足关于数据库与WEB应用服务器之间的数据量传输最小的要求,很多情况下将明显影响性能,严重时甚至会导致WEB应用服务器一端内存溢出。言归正传,我们开始引入我们的方法。
方法一:同分析传统做法类似,我们先列出我们的方法:
select">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个索引关键字,然后再根据索引就可快速的找到记录并返回给用户。从而有效避免了检索全部记录的情况。
set">rudolf@TEST902>set autot trace
set">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逐渐接近满足条件的记录数时,它的性能
也渐渐降低到与传统方法相近的水平:
set">rudolf@TEST902>set autot trace statistics
select">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页。尽管如此,还是有某些应用,用户浏览页面更可能是随机的,这时我们就可以用到第二种方法:
方法二:
select">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个。对于我们“数据库处理量最小”的要求而言,可说是大大迈进了一步。
综上所述,由于用户浏览特点、习惯不同,我们可以采用不同的分页方法,以便更有效的利用资源。