[總結]關於index range scans & INDEX (FAST FULL SCAN)

Q:

對於透過index range scans訪問的表可以透過按索引重建表來提高效率,但是為什麼透過INDEX (FAST FULL SCAN) 訪問的表不能透過重建表來提高效率.

Biti:

index rang scan 是根據索引的葉子block中資料去訪問表，和 key 大小順序一致

index FFS 是根據索引的 extent /block 順序去訪問所有索引block，包括所有葉子和枝節點，這個順序並不和 key 順序一致。

 

Xzh2000:

 

應該可以的.
index rebuild後碎片消除,
肯定會提高效率

Q:

透過index range scans訪問的表可以透過按索引重建表來提高效率, 是因為根據索引的葉子block中資料去訪問表，和 key 大小順序一致,還是重建表以後訪問的資料塊更少.

Biti:

重整表當然可能回解決碎片問題（假如有碎片的話）

但那得看人家說的是啥啊，明顯不是指碎片問題

xzh2000:

 

"透過index range scans訪問的表可以透過按索引重建表來提高效率"
這裡的按索引重建表是什麼意思？

 

Biti:

 

insert into table select * from xxx order by INDEX_KEYS;


oracle 在920 開始，最佳化器對錶順序和索引key順序基本一致的表，做了特別的最佳化處理，即使根據索引訪問整個表，邏輯讀比原來也大大降低。

 

Xzh2000:

INDEX FFS是說如果可以從INDEX上獲取某次訪問所需要的資料，
那就執行INDEX FFS，不需要去訪問表；如果不可以從INDEX上獲
取某次訪問的資料，它可能會執行INDEX FULL SCAN，然後再透過ROWID去訪問DATA BLOCK

 

Q:

 

透過index range scans訪問的表可以透過按索引重建表來提高效率, 是因為根據索引的葉子block中資料去訪問表，和 key 大小順序一致,還是重建表以後訪問的資料塊更少? 它的原理是什麼?

 

quote:

最初由 xzh2000 釋出


INDEX FFS是說如果可以從INDEX上獲取某次訪問所需要的資料，
那就執行INDEX FFS，不需要去訪問表；如果不可以從INDEX上獲
取某次訪問的資料，它可能會執行INDEX FULL SCAN，然後再透過ROWID去訪問DATA BLOCK

Biti:

sorry ,我在這裡錯把 index fast full scan 當成 index full scan 了。


但是 按照索引來重建表就是指的 按照索引順序重新建立表，和 IOT 沒有必然聯絡。IOT 並不是隨便使用的，不同版本有不同的不少限制條件。如果你本來就有個 主鍵，又如何根據新的索引來做 IOT ?



如果你要問重建了表過了一段時間之後順序又不好了怎麼辦，那可以考慮再重建。


index fast full scan 只訪問索引，所以和表無關。

 

最初由 wwllzpz 釋出
透過index range scans訪問的表可以透過按索引重建表來提高效率, 是因為根據索引的葉子block中資料去訪問表，和 key 大小順序一致,還是重建表以後訪問的資料塊更少? 它的原理是什麼?

這個問題和 碎片無關。即使根本沒有碎片也成。

這樣做後在複雜環境下可能會大大減少 IO ，在 920 會大大減少 邏輯讀，你做個測試就知道了。

 

Q:

測試已經做過了,確實可以減少邏輯讀,但是這樣重建表可以減少IO的原理我看了一些資料還是不很清楚.麻煩biti_rainy 解釋一下?

 

Biti:

最初由 wwllzpz 釋出

測試已經做過了,確實可以減少邏輯讀,但是這樣重建表可以減少IO的原理我看了一些資料還是不很清楚.麻煩biti_rainy 解釋一下?

1: 如果你只讀一部分資料，假設20% ，如果表資料順序混亂，實際上可能把整個表都讀進來了。如果表順序和索引一致，則只需要讀進 20%的表的block就夠了。這是簡單情況。


2：複雜情況下，順序混亂的時候 block 可能在整個查詢的不同時間點多次反覆訪問，當再次要訪問這個塊的時候說不定已經被換出去了，或者被修改過了，那代價更大。 而如果順序一樣，對同一個block的訪問集中在一段連續的很短的時間內，變數少，不會對同一個block產生多次 IO

 

 

husthxd:

quote:

最初由 rchsh 釋出
根據索引重建表以後，這樣相臨的資料就集中在很少的資料塊中了，所以可以減少資料塊的讀取

從表統計資訊中的cluster_factor可以判斷是否有很好的聚集性.
btw:
記得有個文件上說ffs比fs快的一個原因是使用了多塊讀.
不清楚索引的多塊讀是否跟表block的多塊讀的機理是否一致?

 

Biti:

 

FFS和FTS是一樣的，所以這樣出來的資料也並不是有序的。只是索引比表小，快一些而已。


如果你建立一個一兩個數字欄位的表，走FFS，反而比FTS慢了，因為索引比表還大

 

INDEX fast full scan 和 index range scan 根本就是不同的概念，你需要先把原理弄清楚再來看錶象

index range scan 是 根據葉子節點的順序去尋找資料，資料出來和索引順序是一致的排好順序的，一次讀一個索引block和一個資料block

index fast full scan 是根據索引 segment 的 extent 去搜尋的，這個跟 FTS 的原理類似，不過 table segment 換成了 index segment ,一次讀可以是連續的多個 index block ，這樣出來的資料順序和 索引順序並不一致。

而我們通常說的利用不上索引 指的 是 index range scan or other index scan ,不是 index fast full scan 。
index fast full scan 的前提是，資料肯定在索引中有（比如not null 的欄位，或者複合索引，bitmap索引等），然後 索引 segment比表 segment小，透過索引segment 能得到所需要資料，而不用去讀 任何表的block，這樣 IO 將減少。

 

Fast Full Index Scans :
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.

Fast full scan is available only with the CBO. You can specify it 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.





Full Table Scans :
This type of scan reads all rows from a table and filters out those that do not meet the selection criteria. During a full table scan, all blocks in the table that are under the high water mark are scanned. Each row is examined to determine whether it satisfies the statement's WHERE clause.

When Oracle performs a full table scan, the blocks are read sequentially. Because the blocks are adjacent, I/O calls larger than a single block can be used to speed up the process. The size of the read calls range from one block to the number of blocks indicated by the initialization parameter DB_FILE_MULTIBLOCK_READ_COUNT. Using multiblock reads means a full table scan can be performed very efficiently. Each block is read only once.