在Oracle9i之前，僅有的兩個CBO模式是ALL_ROWS以及FIRST_ROWS。傳統(tǒng)的FIRST_ROWS SQL最優(yōu)化的缺點之一是，它的運算法則并沒有非凡指定行檢索的范圍。 但是，在Oracle9i中包含了幾個新的最優(yōu)化指令： FIRST_ROWS_1 FIRST_ROWS_10 FIRST_ROWS_100 FIRST_ROWS_1000 FIRST_ROWS_n最優(yōu)化會指示選擇一個查詢執(zhí)行計劃，這個計劃會縮短生成最初n行查詢結(jié)果的時間。 你可以把這個新的CBO模式設(shè)置到數(shù)據(jù)庫中的幾個層次上：systemwide，在會話層或者在查詢層次上。 alter system set optimizer_mode=first_rows_100; alter session set optimizer_mode = first_rows_100; select /*+ first_rows(100) */ from student; 根據(jù)來自O(shè)racle公司的說法，使用FIRST_ROWS_n最優(yōu)化，Oracle查詢能夠使用最少的反應(yīng)時間來給出最初的n行結(jié)果。更快速的給出最初n行的結(jié)果能夠提高用戶對應(yīng)用軟件的滿足程度的原因是由于用戶能夠更為快速的得到最初的那些數(shù)據(jù)。 當(dāng)使用FIRST_ROWS最優(yōu)化索引的時候，ALL_ROWS最優(yōu)化支持完整表的搜尋。但是，Oracle通過FIRST_ROWS_n最優(yōu)化擴展了這個概念的范疇。 在傳統(tǒng)的FIRST_ROWS最優(yōu)化中，Oracle CBO支持索引掃描，甚至當(dāng)全部成本高于完整表掃描的時候也是如此。在對于完整表掃描不太昂貴的較小型表的情況下，這種情況也是尤為明顯。 請看一看下面的這個例子。 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) 現(xiàn)在，我們要使用FIRST_ROWS最優(yōu)化來進行相同的查詢工作。 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能夠?qū)λ饕M行支持，但是我們還是非常驚異的看到選擇了一種比完整表掃描更為昂貴的方式。這是一個臨界點。在Oracle9i之前，F(xiàn)IRST_ROWS最優(yōu)化是一種對內(nèi)部規(guī)則和費用的一種綜合，而且Oracle9i FIRST_ROWS最優(yōu)化也是完全基于成本的。 在Oracle9i之前，我們使用OPTIMIZER_INDEX_COST_ADJ參數(shù)來控制CBO選擇索引。 雖然Oracle公司聲稱FIRST_ROWS_n最優(yōu)化能夠讓查詢變得更加快速，但是要記住， Oracle9i CBO所負(fù)責(zé)的是最初那些行的查詢訪問的成本。換一種說法，所有的FIRST_ROWS_n模式所做的就是決定出更為明智的選擇，決定是使用索引還是使用完整表掃描來進行對小型表的訪問。由于多數(shù)的Oracle9i DBA會把這些小型表存儲于KEEP池中，因此該參數(shù)使用的范圍并不廣。
