大數據oracle分頁查詢
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
- SELECT * FROM
- (
- SELECT A.*, ROWNUM RN
- FROM (SELECT * FROM TABLE_NAME) A
- )
- WHERE RN BETWEEN 21 AND 40
分頁查詢格式2
[sql] view plain copy
- SELECT * FROM
- (
- SELECT A.*, ROWNUM RN
- FROM (SELECT * FROM TABLE_NAME) A
- WHERE ROWNUM <= 40
- )
- WHERE RN >= 21
分頁查詢格式3
考慮到多表聯合的情況，如果不介意在系統中使用HINT的話，可以將分頁的查詢語句改寫為：
[sql] view plain copy
- SELECT /*+ FIRST_ROWS */ * FROM
- (
- SELECT A.*, ROWNUM RN
- FROM (SELECT * FROM TABLE_NAME) A
- WHERE ROWNUM <= 40
- )
- 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
大數據oracle分頁查詢