Oracle的分页查询语句基本上可以按照本文给出的格式来进行套用。
(一) 分页查询格式: SELECT * FROM 其中最内层的查询SELECT * FROM TABLE_NAME表示不进行翻页的原始查询语句。ROWNUM <= 40和RN >= 21控制分页查询的每页的范围。 上面给出的这个分页查询语句,在大多数情况拥有较高的效率。分页的目的就是控制输出结果集大小,将结果尽快的返回。在上面的分页查询语句中,这种考虑主要体现在WHERE ROWNUM <= 40这句上。 选择第21到40条记录存在两种方法,一种是上面例子中展示的在查询的第二层通过ROWNUM <= 40来控制最大值,在查询的最外层控制最小值。而另一种方式是去掉查询第二层的WHERE ROWNUM <= 40语句,在查询的最外层控制分页的最小值和最大值。这是,查询语句如下: SELECT * FROM 对比这两种写法,绝大多数的情况下,第一个查询的效率比第二个高得多。 这是由于CBO优化模式下,Oracle可以将外层的查询条件推到内层查询中,以提高内层查询的执行效率。对于第一个查询语句,第二层的查询条件WHERE ROWNUM <= 40就可以被Oracle推入到内层查询中,这样Oracle查询的结果一旦超过了ROWNUM限制条件,就终止查询将结果返回了。 而第二个查询语句,由于查询条件BETWEEN 21 AND 40是存在于查询的第三层,而Oracle无法将第三层的查询条件推到最内层(即使推到最内层也没有意义,因为最内层查询不知道RN代表什么)。因此,对于第二个查询语句,Oracle最内层返回给中间层的是所有满足条件的数据,而中间层返回给最外层的也是所有数据。数据的过滤在最外层完成,显然这个效率要比第一个查询低得多。 上面分析的查询不仅仅是针对单表的简单查询,对于最内层查询是复杂的多表联合查询或最内层查询包含排序的情况一样有效。 这里就不对包含排序的查询进行说明了,下一篇文章会通过例子来详细说明。下面简单讨论一下多表联合的情况。对于最常见的等值表连接查询,CBO一般可能会采用两种连接方式NESTED LOOP和HASH JOIN(MERGE JOIN效率比HASH JOIN效率低,一般CBO不会考虑)。在这里,由于使用了分页,因此指定了一个返回的最大记录数,NESTED LOOP在返回记录数超过最大值时可以马上停止并将结果返回给中间层,而HASH JOIN必须处理完所有结果集(MERGE JOIN也是)。那么在大部分的情况下,对于分页查询选择NESTED LOOP作为查询的连接方法具有较高的效率(分页查询的时候绝大部分的情况是查询前几页的数据,越靠后面的页数访问几率越小)。 因此,如果不介意在系统中使用HINT的话,可以将分页的查询语句改写为: SELECT /*+ FIRST_ROWS */ * FROM
(二)
这篇文章用几个例子来说明分页查询的效率。首先构造一个比较大的表作为测试表: SQL> CREATE TABLE T AS SELECT * FROM DBA_OBJECTS, DBA_SEQUENCES; 表已创建。 SQL> SELECT COUNT(*) FROM T; COUNT(*) 首先比较两种分页方法的区别: SQL> SET AUTOT ON PL/SQL 过程已成功完成。 SQL> SELECT OBJECT_ID, OBJECT_NAME OBJECT_ID OBJECT_NAME 已选择10行。
Statistics SQL> SELECT OBJECT_ID, OBJECT_NAME OBJECT_ID OBJECT_NAME 已选择10行。
Statistics 二者执行效率相差很大,一个需要8000多逻辑读,而另一个只需要5个逻辑读。观察二者的执行计划可以发现,两个执行计划唯一的区别就是第二个查询在COUNT这步使用了STOPKEY,也就是说,Oracle将ROWNUM <= 20推入到查询内层,当符合查询的条件的记录达到STOPKEY的值,则Oracle结束查询。 因此,可以预见,采用第二种方式,在翻页的开始部分查询速度很快,越到后面,效率越低,当翻到最后一页,效率应该和第一种方式接近。 SQL> SELECT OBJECT_ID, OBJECT_NAME OBJECT_ID OBJECT_NAME 已选择11行。
Statistics
---------------------------------------------------------- 0 recursive calls 0 db block gets 8979 consistent gets 7423 physical reads 0 redo size 680 bytes sent via SQL*Net to client 503 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 11 rows processed (三)
继续看查询的第二种情况,包含表连接的情况: SQL> CREATE TABLE T AS SELECT * FROM DBA_USERS; 表已创建。 SQL> CREATE TABLE T1 AS SELECT * FROM DBA_SOURCE; 表已创建。 SQL> ALTER TABLE T ADD CONSTRAINT PK_T PRIMARY KEY (USERNAME); 表已更改。 SQL> ALTER TABLE T1 ADD CONSTRAINT FK_T1_OWNER FOREIGN KEY (OWNER) 表已更改。 SQL> CREATE INDEX IND_T1_OWNER ON T1(NAME); 索引已创建。 SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(USER, ‘T‘) PL/SQL 过程已成功完成。 SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(USER, ‘T1‘) PL/SQL 过程已成功完成。 创建了T表和T1表,默认情况下,HASH JOIN的效率要比NESTED LOOP高很多: SQL> SET AUTOT TRACE 已选择96985行。
Statistics SQL> SELECT /*+ FIRST_ROWS */ * FROM T, T1 WHERE T.USERNAME = T1.OWNER; 已选择96985行。
但是如果分页查询的内层是这种连接查询的话,使用NESTED LOOP可以更快的得到前N条记录。 下面看一下这种情况下的分页查询情况: SQL> SELECT USER_ID, USERNAME, NAME 已选择10行。
Statistics SQL> SELECT /*+ FIRST_ROWS */ USER_ID, USERNAME, NAME 已选择10行。
看上去似乎HASH JOIN效率更高,难道上面说错了。 其实这个现象是由于这个例子的特殊性造成的。T表是根据DBA_USERS创建,这张表很小。HASH JOIN中第一步也就是第一张表的全表扫描是无法应用STOPKEY的,这就是上面提到的NESTED LOOP比HASH JOIN优势的地方。但是,这个例子中,恰好第一张表很小,对这张表的全扫描的代价极低,因此,显得HASH JOIN效率更高。但是,这不具备共性,如果两张表的大小相近,或者Oracle错误的选择了先扫描大表,则使用HASH JOIN的效率就会低得多。 SQL> SELECT USER_ID, USERNAME, NAME 已选择10行。
Statistics 通过HINT提示,让Oracle先扫描大表,这回结果就很明显了。NESTED LOOP的效果要比HASH JOIN好得多。 下面,继续比较一下两个分页操作的写法,为了使结果更具有代表性,这里都采用了FIRST_ROWS提示,让Oracle采用NESTED LOOP的方式来进行表连接: SQL> SELECT /*+ FIRST_ROWS */ USER_ID, USERNAME, NAME 已选择10行。
SQL> SELECT /*+ FIRST_ROWS */ USER_ID, USERNAME, NAME 已选择10行。
两种写法的效率差别极大。关键仍然是是否能将STOPKEY应用到最内层查询中。 对于表连接来说,在写分页查询的时候,可以考虑增加FIRST_ROWS提示,它有助于更快的将查询结果返回。 其实,不光是表连接,对于所有的分页查询都可以加上FIRST_ROWS提示。不过需要注意的时,分页查询的目标是尽快的返回前N条记录,因此,无论是ROWNUM还是FIRST_ROWS机制都是提高前几页的查询速度,对于分页查询的最后几页,采用这些机制不但无法提高查询速度,反而会明显降低查询效率,对于这一点使用者应该做到心中有数。 |
|
来自: moonboat > 《database》