大数据oracle分页查询

Posted 2020-10-04

 

ROWNUM

 

可能都知道ROWNUM只适用于小于或小于等于，如果进行等于判断，那么只能等于1，不能进行大于的比较。
ROWNUM是oracle系统顺序分配为从查询返回的行的编号，返回的第一行分配的是1，第二行是2，依此类推。
ROWNUM总是从1开始，不管当前的记录是否满足查询结果，ROWNUM返回的值都是1，如果这条记录的值最终满足所有的条件，那么ROWNUM会递加，下一条记录的ROWNUM会返回2，否则下一条记录的ROWNUM仍然返回1。
理解了这一点，就清楚为什么一般的ROWNUM大于某个值或等于某个不为1的值是无法返回结果的，因此对于每条记录的ROWNUM都是1，而ROWNUM为1不满足查询的结果，所以下一条记录的ROWNUM不会递增，仍然是1，因此所有的记录都不满足条件。

 

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

 

[sql] view plain copy

 

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 copy

 

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 copy

 

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，这些方法带来性能提升的前提都是数据量比较小，一旦分页到了最后几页，会发现这些方法不但没有办法带来性能的提升，而且性能比普通查询还要低得多。这一点，在使用分页查询的时候，一定要心里有数。
分页查询一般情况下，很少会翻到最后一篇，如果只是偶尔碰到这种情况，对系统性能不会有很大的影响，但是如果经常碰到这种情况，在设计分页查询时应该给予足够的考虑。

 

 

 

排序列不唯一所带来的问题
如果用来排序的列不唯一，也就是存在值相等的行，可能会造成第一次在前10条返回记录中，某行数据出现了，而第二次在11到第20条记录中，某行数据又出现了。一条数据重复出现两次，就必然意味着有数据在两次查询中都不会出现。
其实造成这个问题的原因很简单，是由于排序列不唯一造成的。Oracle这里使用的排序算法不具有稳定性，也就是说，对于键值相等的数据，这种算法完成排序后，不保证这些键值相等的数据保持排序前的顺序。
解决这个问题其实也很简单。有两种方法可以考虑。
1）在使用不唯一的字段排序时，后面跟一个唯一的字段。
一般在排序字段后面跟一个主键就可以了，如果表不存在主键，跟ROWID也可以。这种方法最简单，且对性能的影响最小。
2）另一种方法就是使用前面给出过多次的BETWEEN AND的方法。
这种方式由于采用表数据的全排序，每次只取全排序中的某一部分数据，因此不会出现上面提到的重复数据问题。
但是正是由于使用了全排序，而且ROWNUM信息无法推到查询内部，导致这种写法的执行效率很低

 

 

 

 

 

 

 

转载：http://blog.csdn.net/fw0124/article/details/42737671