在Oracle9i之前，僅有的兩個CBO模式是ALL_ROWS以及FIRST_ROWS。傳統的FIRST_ROWS SQL最優化的缺點之一是，它的運算法則并沒有非凡指定行檢索的范圍。 但是，在Oracle9i中包含了幾個新的最優化指令： FIRST_ROWS_1 FIRST_ROWS_10 FIRST_ROWS_100 FIRST_ROWS_1000 FIRST_ROWS_n最優化會指示選擇一個查詢執行計劃，這個計劃會縮短生成最初n行查詢結果的時間。 你可以把這個新的CBO模式設置到數據庫中的幾個層次上：systemwide，在會話層或者在查詢層次上。 alter system set optimizer_mode=first_rows_100;alter session set optimizer_mode = first_rows_100;select /*+ first_rows(100) */ from student;根據來自Oracle公司的說法，使用FIRST_ROWS_n最優化，Oracle查詢能夠使用最少的反應時間來給出最初的n行結果。更快速的給出最初n行的結果能夠提高用戶對應用軟件的滿足程度的原因是由于用戶能夠更為快速的得到最初的那些數據。 當使用FIRST_ROWS最優化索引的時候，ALL_ROWS最優化支持完整表的搜尋。但是，Oracle通過FIRST_ROWS_n最優化擴展了這個概念的范疇。 在傳統的FIRST_ROWS最優化中，Oracle CBO支持索引掃描，甚至當全部成本高于完整表掃描的時候也是如此。在對于完整表掃描不太昂貴的較小型表的情況下，這種情況也是尤為明顯。 請看一看下面的這個例子。 Set autotrace on eXPlainalter session set optimizer_goal = choose;select * from emp where sal < 1200;PLAN SELECT STATEMENT (OPTIMIZER=CHOOSE) (COST=62) (ROWS=99)TABLE Access FULL EMP (COST=62) (ROWS=99)現在，我們要使用FIRST_ROWS最優化來進行相同的查詢工作。 alter session set optimizer_goal = first_rows;select * from emp where sal < 1200;The explain plan is now transformed to:PLAN SELECT STATEMENT (OPTIMIZER=FIRST_ROWS) (COST=102)TABLE ACCESS BY INDEX ROWID EMP (COST=102) (ROWS=99)INDEX RANGE SCAN SA L_IDX (COST=2) (ROWS=99)我們希望CBO能夠對索引進行支持，但是我們還是非常驚異的看到選擇了一種比完整表掃描更為昂貴的方式。這是一個臨界點。在Oracle9i之前，FIRST_ROWS最優化是一種對內部規則和費用的一種綜合，而且Oracle9i FIRST_ROWS最優化也是完全基于成本的。 在Oracle9i之前，我們使用OPTIMIZER_INDEX_COST_ADJ參數來控制CBO選擇索引。雖然Oracle公司聲稱FIRST_ROWS_n最優化能夠讓查詢變得更加快速，但是要記住， Oracle9i CBO所負責的是最初那些行的查詢訪問的成本。換一種說法，所有的FIRST_ROWS_n模式所做的就是決定出更為明智的選擇，決定是使用索引還是使用完整表掃描來進行對小型表的訪問。由于多數的Oracle9i DBA會把這些小型表存儲于KEEP池中，因此該參數使用的范圍并不廣。