Oracle ROWNUM用法和分頁查詢總結____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
在查詢的最外層控制分頁的最小值和最大值。查詢語句如下：

SELECT * FROM (SELECT A.*, ROWNUM RN FROM (SELECT * FROM TABLE_NAME) A )WHERE RN BETWEEN 21 AND 40

分頁查詢格式2

SELECT * FROM (SELECT A.*, ROWNUM RN FROM (SELECT * FROM TABLE_NAME) A WHERE ROWNUM <= 40)WHERE RN >= 21

分頁查詢格式3
考慮到多表聯合的情況，如果不介意在系統中使用HINT的話，可以將分頁的查詢語句改寫為：

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，這些方法帶來效能提升的前提都是資料量比較小，一旦分頁到了最後幾頁，會發現這些方法不但沒有辦法帶來效能的提升，而且效能比普通查詢還要低得多。這一點，在使用分頁查詢的時候，一定要心裡有數。
分頁查詢一般情況下，很少會翻到最後一篇，如果只是偶爾碰到這種情況，對系統效能不會有很大的影響，但是如果經常碰到這種情況，在設計分頁查詢時應該給予足夠的考慮。

多表聯合
下面簡單討論一下多表聯合的情況。對於最常見的等值表串連查詢，CBO一般可能會採用兩種串連方式NESTED LOOP和HASH JOIN（MERGE JOIN效率比HASH JOIN效率低，一般CBO不會考慮）。
一般對於大表查詢情況下，HASH JOIN的效率要比NESTED LOOP高很多，所以CBO一般預設會選擇HASH JOIN.

但是如果分頁查詢的內層是這種串連查詢的話，使用NESTED LOOP可以更快的得到前N條記錄。
在這裡，由於使用了分頁，因此指定了一個返回的最大記錄數，NESTED LOOP在返回記錄數超過最大值時可以馬上停止並將結果返回給中介層，而HASH JOIN必須處理完所有結果集（MERGE JOIN也是）。那麼在大部分的情況下，對於分頁查詢選擇NESTED LOOP作為查詢的串連方法具有較高的效率（分頁查詢的時候絕大部分的情況是查詢前幾頁的資料，越靠後面的頁數訪問幾率越小）。

HASH JOIN中第一步也就是第一張表的全表掃描是無法應用STOPKEY的，這就是NESTED LOOP比HASH JOIN優勢的地方。
但是，如果恰好第一張表很小，對這張表的全掃描的代價極低，會顯得HASH JOIN效率更高。
如果兩張表的大小相近，或者Oracle錯誤的選擇了先掃描大表，則使用HASH JOIN的效率就會低得多。

因此對於表串連來說，在寫分頁查詢的時候，可以考慮增加FIRST_ROWS提示，它會導致CBO選擇NESTED LOOP，有助於更快的將查詢結果返回。
其實，不光是表串連，對於所有的分頁查詢都可以加上FIRST_ROWS提示。
不過需要注意的時，分頁查詢的目標是儘快的返回前N條記錄，因此，無論是ROWNUM還是FIRST_ROWS機制都是提高前幾頁的查詢速度，
對於分頁查詢的最後幾頁，採用HASH JOIN的方式，執行效率幾乎沒有任何改變，而採用NESTED LOOP方式，則效率嚴重下降，而且遠遠低於HASH JOIN的方式。

排序列不唯一所帶來的問題
如果用來排序的列不唯一，也就是存在值相等的行，可能會造成第一次在前10條返回記錄中，某行資料出現了，而第二次在11到第20條記錄中，某行資料又出現了。一條資料重複出現兩次，就必然意味著有資料在兩次查詢中都不會出現。
其實造成這個問題的原因很簡單，是由於排序列不唯一造成的。Oracle這裡使用的排序演算法不具有穩定性，也就是說，對於索引值相等的資料，這種演算法完成排序後，不保證這些索引值相等的資料保持排序前的順序。
解決這個問題其實也很簡單。有兩種方法可以考慮。
1）在使用不唯一的欄位排序時，後面跟一個唯一的欄位。
一般在排序欄位後面跟一個主鍵就可以了，如果表不存在主鍵，跟ROWID也可以。這種方法最簡單，且對效能的影響最小。
2）另一種方法就是使用前面給出過多次的BETWEEN AND的方法。
這種方式由於採用表資料的全排序，每次只取全排序中的某一部分資料，因此不會出現上面提到的重複資料問題。
但是正是由於使用了全排序，而且ROWNUM資訊無法推到查詢內部，導致這種寫法的執行效率很低