在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 explain
alter 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池中，因此該參數使用的範圍並不廣。（T004）
