為了實現(xiàn)Oracle關(guān)于增加SQL優(yōu)化查詢智能的承諾，Oracle9i增強了全索引SQL執(zhí)行計劃以支持基于功能的索引（function-based index）。在Oracle 8i中，SQL優(yōu)化器添加了判定查詢是否可以專門用一個現(xiàn)存的索引來解決的智能。一旦存在索引，Oracle就會繞過對表的訪問，索引組織表（index-organized table，IOT）結(jié)構(gòu)就是一個例子。在IOT結(jié)構(gòu)中，所有的數(shù)據(jù)都載入索引的b-樹結(jié)構(gòu)，這樣表（table）就成為一個多余的東西了。 一旦Oracle SQL優(yōu)化器檢測到查詢無需訪問表時，Oracle就調(diào)用全索引掃描并快速讀取每一個索引塊而無需接觸表本身。有一點很重要：全索引掃描并沒有讀取索引節(jié)點，而是一塊一塊的執(zhí)行掃描并快速捕捉索引節(jié)點。最好，Oracle調(diào)用多塊讀取功能，調(diào)用多個過程來讀取表。 Oracle和多塊讀取 為了加快表和索引的訪問速度，Oracle使用了db_file_multiblock_read_count參數(shù)（默認參數(shù)為8）來輔助把全表掃描和全索引掃描所獲得的數(shù)據(jù)塊盡快送到數(shù)據(jù)緩沖區(qū)中。然而，這個參數(shù)只有當(dāng)SQL查詢執(zhí)行全表掃描時才可用，并且，在絕大多數(shù)情況下，查詢要使用索引來訪問表。 Oracle對全索引掃描有如下限制： SQL請求的全部列（column）必須駐留在索引樹中；也就是說，SELECT和WHERE字句中的所有數(shù)據(jù)列必須存在于索引中。 查詢訪問大量的行（row）。根據(jù)你查詢的范圍，比例變化范圍為10％到25％之間，這個比例參數(shù)db_file_multiblock_read_count的設(shè)置和查詢的并行程度極大的影響到這個比例。 由于索引節(jié)點并沒有按索引順序排列，所以列并沒有順序。這樣，ORDER BY字句將要求附加的排序操作。 Oracle提供了一個SQL提示（hint）來強制全索引掃描。你也可以通過指定index_ffs提示來強制快速索引掃描，這經(jīng)常與parallel_index提示組合來提高性能。例如，下面的查詢強迫使用并行快速全索引掃描： select distinct /*+ index_ffs(c,pk_auto) parallel_index_ (automobile, pk_auto) color, count(*)fromautomobilesgroup by color;由于涉及了所有的變量，所以全索引是否會加快查詢速度并不能簡單的加以回答。所以，大多數(shù)有經(jīng)驗的SQL調(diào)試者（tuner）會對符合快速全索引掃描標(biāo)準(zhǔn)的查詢進行手工計時，看看使用全索引掃描的反映時間是否會降低。 函數(shù)索引基礎(chǔ) 在Oracle9i之前，全索引掃描只有當(dāng)創(chuàng)建的索引沒有空值時才可以使用，也就是說，Oracle建立索引時必須用一個NOT NULL子句才可以使用該索引。由于Oracle9i支持用函數(shù)（function-based）索引實現(xiàn)的唯索索引掃描，這種情況大大改觀。 簡單回歸一下，函數(shù)索引是Oracle8的一個重要改進，因為它提供了一種有效的消除無必要長表全掃描的機制，由于函數(shù)索引可以在任何查詢語句中的WHERE子句中精確復(fù)制，Oracle總會用一個索引來匹配上SQL查詢的WHERE子句。 現(xiàn)在，我要會用一個student表來舉一個簡單的例子來解釋全索引掃描如何與函數(shù)索引一起工作的過程。 創(chuàng)建student表 (student_name varchar2(40), date_of_birth date); 使用這個表，創(chuàng)建與表中所有列相關(guān)聯(lián)的函數(shù)索引。在本例中，該函數(shù)為initcap（即大寫每個單詞的首字母）和to_char（即把一個數(shù)字變成字符）： create index whole_studenton student(initcap(student_name), to_char(date_of_birth,’MM-DD-YY’));定義完函數(shù)索引后，Oracle9i中任何可以引用這些列（column）的SQL語句都可以使用全索引掃描。下面是SQL匹配函數(shù)索引的查詢例子： select * from studentwhere initcap(student_name) = ‘Jones’;select * from studentwhere to_char(date_of_birth,’MM-DD=YY’) = ’04-07-85’;用函數(shù)索引來調(diào)用全索引掃描 Oracle9i只要可能就會使用函數(shù)索引并在函數(shù)索引的基礎(chǔ)上調(diào)用全索引掃描。假如SQL優(yōu)化器統(tǒng)計結(jié)果表明使用全索引掃描的速度將會超過通過索引的b-樹訪問的速度，那么Oracle9i就會這么做。 下面是用函數(shù)索引調(diào)用唯索掃描的準(zhǔn)則。所有的SQL謂詞匹配索引中的列，查詢必須從表中返回足夠多的行，這樣做的目的是為了讓代價優(yōu)化器（cost-based optimizer）來判定全索引掃描是否要比傳統(tǒng)的索引訪問方法要快。是否調(diào)用全索引掃描的決定取決于下面幾個參數(shù)設(shè)置： 代價優(yōu)化器的適當(dāng)統(tǒng)計數(shù)字——這個計劃（schema）最近已經(jīng)分析過了，而且optimizer_mode參數(shù)不能設(shè)置為RULE。 索引的并行程度——注重索引的并行程度是獨立設(shè)置的；索引并沒有繼續(xù)表的并行程度。 optimizer_index_cost_adj的設(shè)置——它控制代價優(yōu)化器是否傾向于全索引掃描。 db_file_multiblock_read_count的設(shè)置——這個參數(shù)影響到全索引掃描的代價。這個值越高，全索引掃描的代價也就會越“便宜”。 索引的直方圖表示——對偏移（skewed）索引，它幫助代價優(yōu)化器評估查詢返回的行數(shù)。 Oracle的一個重要提高 在函數(shù)索引基礎(chǔ)上的快速全索引掃描是Oracle9i的另一個提高性能的途徑。當(dāng)數(shù)據(jù)庫遷移到Oracle9i時，許多數(shù)據(jù)庫自動開始使用這個新的執(zhí)行計劃。不過，當(dāng)SQL代價優(yōu)化器決定是否選擇全索引掃描時，還要考慮幾個因素。Oracle專業(yè)人員需要適當(dāng)設(shè)置參數(shù)，以確保代價優(yōu)化器不會用不合適的方式使用快速全索引掃描——這一點需要非凡注重。