oracle表通路方式

<a href="http://www.cnblogs.com/tracy/archive/2011/09/02/2163462.html">Index Full Scan &amp;&amp; Index Range Scan</a>

<a href="http://blog.sina.com.cn/s/blog_4ca246370100tkrl.html">oracle-index unique scan 與index range scan等的差別</a>

<a href="http://blog.csdn.net/robinson1988/article/details/4980611">index range scan,index fast full scan,index skip scan發生的條件</a>

<a href="http://blog.csdn.net/robinson_0612/article/details/7474308">Oracle ROWID 方式通路資料庫</a>

<a href="http://www.cnblogs.com/liuqiongliu/archive/2011/03/31/2000876.html">oracle優化3（通路Table的方式）</a>

oracle 通路表中記錄有三種方式：

ORACLE 采用三種通路表中記錄的方式: 全表掃描、通過ROWID通路表、索引掃描

　　為實作全表掃描，Oracle順序地通路表中每條記錄，并檢查每一條記錄是否滿足WHERE語句的限制條件。ORACLE采用一次讀入多個資料塊(database block)的方式優化全表掃描，而不是隻讀取一個資料塊，這極大的減少了I/O總次數，提高了系統的吞吐量，是以利用多塊讀的方法可以十分高效地實作全表掃描。需要注意的是隻有在全表掃描的情況下才能使用多塊讀操作。在這種通路模式下，每個資料塊隻被讀一次。

　　使用FTS的前提條件：在較大的表上不建議使用全表掃描，除非取出資料的比較多，超過總量的5% -- 10%，或你想使用并行查詢功能時。

建立表并插入資料，并進行查詢。

View Code

從查詢計劃我們可以看到所采用的查詢方式是“TABLE ACCESS FULL”，這就是全表掃描。也正是因為采用全表掃描，是以consistent gets會很大。

　　ROWID指出了該行所在的資料檔案、資料塊以及行在該塊中的位置，是以通過ROWID來存取資料可以快速定位到目标資料上，是Oracle存取單行資料的最快方法。為了通過ROWID存取表，Oracle 首先要擷取被選擇行的ROWID，或者從語句的WHERE子句中得到，或者通過表的一個或多個索引的索引掃描得到。Oracle然後以得到的ROWID為依據定位每個被選擇的行。下面給出使用rowid通路表的執行個體。

查詢計劃中說明該查詢是的表通路方式是”TABLE ACCESS BY USER ROWID“，也就是直接通過USER ROWID來通路，這也是為什麼隻需要1次consistent gets的原因。

使用如下查詢進行範圍查詢

查詢計劃分析：

上面的執行計劃中出現了INLIST ITERATOR，即INLIST疊代，該操作說明其子操作多次重複時，會出現該操作。  

由于我們使用了in運算，且傳遞了2個rowid，故出現INLIST疊代操作

疊代操作意味着條件中的對象清單一個接一個的疊代傳遞給子操作

此時統計資訊中的consistent gets為2，并不是因為傳入的rowid有2個，假如傳入的rowid有4個，consistent gets也等于4。

注意：使用ROWID進行查詢的前提是我們明确知道了一個正确的ROWID，然後通過這個ROWID進行查詢。是以這裡所提到的所有ROWID必須是真實存在的，否則會報錯。

　　我們先通過index查找到資料對應的rowid值(對于非唯一索引可能傳回多個rowid值)，然後根據rowid直接從表中得到具體的資料，這種查找方式稱為索引掃描或索引查找(index lookup)。一個rowid唯一的表示一行資料，該行對應的資料塊是通過一次i/o得到的，在此情況下該次i/o隻會讀取一個資料庫塊。

　　在索引中，除了存儲每個索引的值外，索引還存儲具有此值的行對應的ROWID值。索引掃描可以由2步組成：(1) 掃描索引得到對應的rowid值。 (2) 通過找到的rowid從表中讀出具體的資料。

　　根據索引的類型與where限制條件的不同，有4種類型的索引掃描。

　　使用一個索引存取多行資料，在唯一索引上使用索引範圍掃描的典型情況下是在謂詞(where限制條件)中使用了範圍操作符(如&gt;、&lt;、&lt;&gt;、&gt;=、&lt;=、between)。在非唯一索引上，謂詞"="也可能傳回多行資料，是以在非唯一索引上都使用索引範圍掃描。

使用index rang scan的3種情況：

在唯一索引列上使用了range操作符(&gt; &lt; &lt;&gt; &gt;= &lt;= between)

在組合索引上，隻使用部分列進行查詢，導緻查詢出多行

對非唯一索引列上進行的任何查詢。

跟全表掃描一樣，使用userinfo表作為執行個體介紹

通過唯一索引查找一個數值經常傳回單個ROWID。如果存在UNIQUE 或PRIMARY KEY 限制(它保證了語句隻存取單行)的話，Oracle經常實作唯一性掃描。

下面依然以userinfo表為例進行舉例說明。首先删除原先在no字段上建立的索引，然後将no字段設為主鍵，再進行“=”的查詢，比如查詢no=5000的字段，代碼執行個體如下：

 有順序的輸出，不能并行通路索引。

　　Fast full index scans are an alternative to a full table scan when the index contains all the columns that are needed for the query（組合索引中的列包含了需要查詢的所有列）, and at least one column in the index key has the NOT NULL constraint（至少有一個有非空限制）. A fast full scan accesses the data in the index itself, without accessing the table. It cannot be used to eliminate a sort operation, because the data is not ordered by the index key. It reads the entire index using multiblock reads, unlike a full index scan, and can be parallelized.

　　You can specify fast full index scans with the initialization parameter OPTIMIZER_FEATURES_ENABLE or the INDEX_FFS hint. Fast full index scans cannot be performed against bitmap indexes.

　　A fast full scan is faster than a normal full index scan in that it can use multiblock I/O（一次可以讀多個塊，跟全表掃描一樣） and can be parallelized just like a table scan.

Index Skip Scans

Index skip scans improve index scans by no nprefix columns. Often, scanning index blocks is faster than sc anning table data blocks.

Skip scanning lets a composite index be split logically into smaller subindexes. In skip scanning, the initial column of the composite index is not specified in the query. In other words, it is skipped.

The number of logical subindexes is determined by the number of distinct values in the initial column. Skip scanning is advantageo us if there are few distinct values in the leading column of the composite index and many distinct values in the nonleading key of the index.

當查詢可以通過組合索引得到結果，而且傳回結果很少，并且where條件中沒有包含索引引導列的時候，可能執行index skip scan。

索引跳躍式掃描發生的條件:

必須是組合索引。

引導列沒有出現在where條件中。

本文轉自xwdreamer部落格園部落格，原文連結：http://www.cnblogs.com/xwdreamer/archive/2012/06/13/2547825.html，如需轉載請自行聯系原作者