oracle rownum原理和使用

小咪咪 2022-08-21 14:45 287阅读 0赞

对于Oracle的rownum问题，很多资料都说不支持>，>=，=，between……and，只能用以上符号（<、& lt;=、！=），并非说用>，>=，=，between……and 时会提示SQL语法错误，而是经常是查不出一条记录来，还会出现似乎是莫名其妙的结果来，其实您只要理解好了这个rownum伪列的意义就不应该感到惊 奇，同样是伪列，rownum与rowid可有些不一样，下面以例子说明：

假设某个表t1（c1）有20条记录。

如果用select rownum，c1 from t1 where rownum < 10，只要是用小于号，查出来的结果很容易地与一般理解在概念上能达成一致，应该不会有任何疑问的。

可如果用select rownum，c1 from t1 where rownum > 10（如果写下这样的查询语句，这时候在您的头脑中应该是想得到表中后面10条记录），你就会发现，显示出来的结果要让您失望了，也许您还会怀疑是不谁删 了一些记录，然后查看记录数，仍然是20条啊？那问题是出在哪呢？

先好好理解rownum的意义吧。因为ROWNUM是对结果集加的一 个伪列，即先查到结果集之后再加上去的一个列 （强调：先要有结果集）。简单的说rownum是对符合条件结果的序列号。它总是从1开始排起的。所以你选出的结果不可能没有1，而有其他大于1的值。所 以您没办法期望得到下面的结果集：

11 aaaaaaaa

12 bbbbbbb

13 ccccccc……

rownum >10 没有记录，因为第一条不满足去掉的话，第二条的ROWNUM又成了1，所以永远没有满足条件的记录。或者可以这样理解：

ROWNUM是一个序列，是oracle数据库从数据文件或缓冲区中读取数据的顺序。它取得第一条记录则rownum值为1，第二条为2，依次类推。如 果你用>，>=，=，between……and这些条件，因为从缓冲区或数据文件中得到的第一条记录的rownum为1，则被删除，接着取下 条，可是它的rownum还是1，又被删除，依次类推，便没有了数据。

有了以上从不同方面建立起来的对rownum的概念，那我们可以来认识使用 rownum 的几种现像

1. select rownum，c1 from t1 where rownum ！= 10 为何是返回前9条数据呢？它与 select rownum，c1 from tablename where rownum < 10 返回的结果集是一样的呢？

因为是在查 询到结果集后，显示完第 9 条记录后，之后的记录也都是 ！= 10，或者 >=10，所以只显示前面9条记录。也可以这样理解，rownum 为9后的记录的 rownum为10，因条件为 ！=10，所以去掉，其后记录补上，rownum又是10，也去掉，如果下去也就只会显示前面9条记录了

2. 为什么 rownum >1 时查不到一条记录，而 rownum >0 或 rownum >=1 却总显示所以的记录因为 rownum 是在查询到的结果集后加上去的，它总是从1开始

3. 为什么 between 1 and 10 或者 between 0 and 10 能查到结果，而用 between 2 and 10 却得不到结果原因同上一样，因为 rownum 总是从 1 开始

从上可以看出，任何时候想把 rownum = 1 这条记录抛弃是不对的，它在结果集中是不可或缺的，少了rownum=1 就像空中楼阁一般不能存在，所以你的 rownum 条件要包含到 1

但如果就是想要用 rownum > 10这种条件的话话就要用嵌套语句，把rownum先生成，然后对他进行查询。

select \*

from （selet rownum as rn，t1.\* from a where ……）

where rn >10

一般代码中对结果集进行分页就是这么干的。

另外：rowid与rownum虽都被称为伪列，但它们的存在方式是不一样的，rowid可以说是物理存在的，表示记录在表空间中的唯一位置ID，在 DB中唯一。只要记录没被搬动过，rowid是不变的。rowid相对于表来说又像表中的一般列，所以rowid为条件就不会有 rownum那些情况发生。

**分页查询格式1**  
在查询的最外层控制分页的最小值和最大值。查询语句如下：

**\[sql\]** [ view plain][view plain] [ copy][view plain] [![在CODE上查看代码片][CODE]][CODE_CODE] [![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  SELECT \* FROM
2.  (
3.  SELECT A.\*, ROWNUM RN
4.  FROM (SELECT \* FROM TABLE\_NAME) A
5.  )
6.  WHERE RN BETWEEN 21 AND 40

**分页查询格式2**

**\[sql\]** [ view plain][view plain] [ copy][view plain] [![在CODE上查看代码片][CODE]][CODE_CODE] [![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  SELECT \* FROM
2.  (
3.  SELECT A.\*, ROWNUM RN
4.  FROM (SELECT \* FROM TABLE\_NAME) A
5.  WHERE ROWNUM <= 40
6.  )
7.  WHERE RN >= 21

**分页查询格式3**  
考虑到多表联合的情况，如果不介意在系统中使用HINT的话，可以将分页的查询语句改写为：

**\[sql\]** [ view plain][view plain] [ copy][view plain] [![在CODE上查看代码片][CODE]][CODE_CODE] [![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  SELECT /\*+ FIRST\_ROWS \*/ \* FROM
2.  (
3.  SELECT A.\*, ROWNUM RN
4.  FROM (SELECT \* FROM TABLE\_NAME) A
5.  WHERE ROWNUM <= 40
6.  )
7.  WHERE RN >= 21

**效率问题**  
对比这两种写法，**绝大多数的情况下，第2个查询的效率比第1个高得多。**  
这是由于CBO优化模式下，Oracle可以将外层的查询条件推到内层查询中，以提高内层查询的执行效率。对于第2个查询语句，第二层的查询条件WHERE ROWNUM <= 40就可以被Oracle推入到内层查询中，这样Oracle查询的结果一旦超过了ROWNUM限制条件，就终止查询将结果返回了。  
而第1个查询语句，由于查询条件BETWEEN 21 AND 40是存在于查询的第三层，而Oracle无法将第三层的查询条件推到最内层（即使推到最内层也没有意义，因为最内层查询不知道RN代表什么）。因此，对于第1个查询语句，Oracle最内层返回给中间层的是所有满足条件的数据，而中间层返回给最外层的也是所有数据。数据的过滤在最外层完成，显然这个效率要比第一个查询低得多。  
上面分析的查询不仅仅是针对单表的简单查询，对于最内层查询是复杂的多表联合查询或最内层查询包含排序的情况一样有效。  
  
观察上面格式1和格式2二者的执行计划可以发现，两个执行计划唯一的区别就是格式2的查询在COUNT这步使用了STOPKEY，也就是说，Oracle将ROWNUM <= 20推入到查询内层，当符合查询的条件的记录达到STOPKEY的值，则Oracle结束查询。因此，可以预见，采用第二种方式，在翻页的开始部分查询速度很快，越到后面，效率越低，当翻到最后一页，效率应该和第一种方式接近。  
  
分页查询语句之所以可以很快的返回结果，是因为它的目标是最快的返回第一条结果。如果每页有20条记录，目前翻到第5页，那么只需要返回前100条记录都可以满足查询的要求了，也许还有几万条记录也符合查询的条件，但是由于分页的限制，在当前的查询中可以忽略这些数据，而只需尽快的返回前100条数据。这也是为什么在标准分页查询语句中经常会使用FIRST\_ROWS提示的原因。  
对于行操作，可以在得到结果的同时将结果直接返回给上一层调用。但是对于结果集操作，Oracle必须得到结果集中所有的数据，因此分页查询中所带的ROWNUM信息不起左右。如果最内层的子查询中包含了下面这些操作中的一个以上，则分页查询语句无法体现出任何的性能优势：UNION、UNION ALL、MINUS、INTERSECT、GROUP BY、DISTINCT、UNIQUE以及聚集函数如MAX、MIN和分析函数等。  
  
Oracle10g的新功能GROUP BY STOPKEY，使得Oracle10g解决了GROUP BY操作分页效率低的问题。在10g以前，Oracle的GROUP BY操作必须完全执行完，才能将结果返回给用户。但是Oracle10g增加了GROUP BY STOPKEY执行路径，使得用户在执行GROUP BY操作时，可以根据STOPKEY随时中止正在运行的操作。这使得标准分页函数对于GROUP BY操作重新发挥了作用。  
  
除了这些操作以外，分页查询还有一个很明显的特点，就是处理的页数越小，效率就越高，越到后面，查询速度越慢。  
分页查询用来提高返回速度的方法都是针对数据量较小的前N条记录而言。无论是索引扫描，NESTED LOOP连接，还是ORDER BY STOPKEY，这些方法带来性能提升的前提都是数据量比较小，一旦分页到了最后几页，会发现这些方法不但没有办法带来性能的提升，而且性能比普通查询还要低得多。这一点，在使用分页查询的时候，一定要心里有数。  
分页查询一般情况下，很少会翻到最后一篇，如果只是偶尔碰到这种情况，对系统性能不会有很大的影响，但是如果经常碰到这种情况，在设计分页查询时应该给予足够的考虑。

[view plain]: http://blog.csdn.net/fw0124/article/details/42737671#
[CODE]: https://code.csdn.net/assets/CODE_ico.png
[CODE_CODE]: https://code.csdn.net/snippets/580453
[ico_fork.svg]: https://code.csdn.net/assets/ico_fork.svg
[ico_fork.svg 1]: https://code.csdn.net/snippets/580453/fork