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