再實際操作中我們為了實現Oracle數據庫關於增加SQL優化查詢智能的保證，Oracle 9i增強了全索引，SQL執行計劃以支持基於功能的相關索引（function-based index）。在Oracle 8i中，SQL優化器添加了判斷查詢是否可以專門用一個現存的索引來解決的智能。
一旦存在索引，Oracle就會繞過對表的訪問，索引組織表（index-organized table，IOT）結構就是一個例子。
在IOT結構中，所有的數據都載入索引的b-樹結構，這樣表（table）就成為一個多余的東西了。
一旦Oracle SQL優化器檢測到查詢無需訪問表時，Oracle就調用全索引掃描並快速讀取每一個索引塊而無需接觸表本身。有一點很重要：全索引掃描並沒有讀取索引節點，而是一塊一塊的執行掃描並快速捕獲索引節點。最好，Oracle調用多塊讀取功能，調用多個過程來讀取表。
Oracle和多塊讀取
為了加快表和索引的訪問速度，Oracle使用了db_file_multiblock_read_count參數（默認參數為8）來輔助把全表掃描和Oracle 9i全索引掃描所獲得的數據塊盡快送到數據緩沖區中。然而，這個參數只有當SQL查詢執行全表掃描時才可用，並且，在絕大多數情況下，查詢要使用索引來訪問表。
Oracle對全索引掃描有如下限制：
SQL請求的全部列（column）必須駐留在索引樹中；也就是說，SELECT和WHERE字句中的所有數據列必須存在於索引中。
查詢訪問大量的行（row）。根據你查詢的范圍，比例變化范圍為10％到25％之間，這個比例參數db_file_multiblock_read_count的設置和查詢的並行程度極大的影響到這個比例。
由於索引節點並沒有按索引順序排列，所以列並沒有順序。這樣，ORDER BY字句將要求附加的排序操作。
Oracle提供了一個SQL提示（hint）來強制Oracle 9i全索引掃描。你也可以通過指定index_ffs提示來強制快速索引掃描，這常常與parallel_index提示組合來提高性能。例如，下面的查詢強迫使用並行快速全索引掃描：
- select distinct /*+ index_ffs(c,pk_auto) parallel_index_
- (automobile, pk_auto) color, count(*)
- from
- automobiles
- group by color;
由於涉及了所有的變量，所以全索引是否會加快查詢速度並不能簡單的加以回答。所以，大多數有經驗的SQL調試者（tuner）會對符合快速Oracle 9i全索引掃描標准的查詢進行手工計時，看看使用全索引掃描的反映時間是否會降低。
