導讀:1建站知識Oracle Index 的三個問題如何seo優化推廣網站個業網站建設公司。

正在看的ORACLE教程是:Oracle Index 的三個問題。

　索引( Index )是常見的數據庫對象，它的設置好壞、使用是否得當，極大地影響數據庫應用程序和Database 的性能。雖然有許多資料講索引的用法， DBA 和 Developer 們也經常與它打交道，但筆者發現，還是有不少的人對它存在誤解，因此針對使用中的常見問題，講三個問題。此文所有示例所用的數據庫是 Oracle 8.1.7 OPS on HP N series ,示例全部是真實數據，讀者不需要注意具體的數據大小，而應注意在使用不同的方法后，數據的比較。本文所講基本都是陳詞濫調，但是筆者試圖通過實際的例子，來真正讓您明白事情的關鍵。  　　第一講、索引并非總是最佳選擇  　　如果發現Oracle 在有索引的情況下，沒有使用索引，這并不是Oracle 的優化器出錯。在有些情況下，Oracle 確實會選擇全表掃描（Full Table Scan）,而非索引掃描（Index Scan）。這些情況通常有：  　　1. 表未做statistics, 或者&nseo網站優化軟件bsp;statistics&n如何seo優化推廣網站bsp;陳舊，導致 Oracle 判斷失誤。  　　2. 根據該表擁有的記錄數和數據塊數，實際上全表掃描要比索引掃描更快。  　　對第1種情況，最常見的例子，是以下這句sql 語句：  　　在未作statistics 之前，它使用全表掃描，需要讀取6000多個數據塊（一個數據塊是8k）, 做了statistics 之后，使用的是 INDEX (FAST FULL SCAN) ，只需要讀取450個數據塊。但是，statistics 做得不好，也會導致Oracle 不使用索引。  　　第2種情況就要復雜得多。一般概念上都認為索引比表快，比較難以理解什么情況下全表掃描要比索引掃描快。為了講清楚這個問題，這里先介紹一下Oracle 在評估使用索引的代價（cost）時兩個重要的數據：CF(Clustering factor) 和 FF(Filtering factor).  　　CF: 所謂 CF, 通俗地講，就是每讀入一個索引塊，要對應讀入多少個數據塊。  　　FF: 所謂 FF, 就是該sql 語句所選擇的結果集，占總的數據量的百分比。  　　大約的計算公式是：FF * (CF + 索引塊個數) ，由此估計出，一個查詢， 如果使用某個索引，會需要讀入的數據塊塊數。需要讀入的數據塊越多，則 cost 越大，Oracle 也就越可能不選擇使用 index. （全表掃描需要讀入的數據塊數等于該表的實際數據塊數）  　　其核心就是， CF 可能會比實際的數據塊數量大。CF 受到索引中數據的排列方式影響，通常在索引剛建立時，索引中的記錄與表中的記錄有良好的對應關系，CF 都很小；在表經過大量的插入、修改后，這種對應關系越來越亂，CF 也越來越大。此時需要 DBA 重新建立或者組織該索引。  　　如果某個sql 語句以前一直使用某索引，較長時間后不再使用，一種可能就是 CF 已經變得太大，需要重新整理該索引了。  　　FF 則是Oracle 根據 statistics 所做的估計。比如, mytables 表有32萬行，其主鍵myid的最小值是1，最大值是409654，考慮以下sql 語句：  　　這兩句看似差不多的 sql 語句，對Oracle 而言，卻有巨大的差別。因為前者的 FF 是100%， 而后者的 FF 可能只有 1%。如果它的CF 大于實際的數據塊數，則Oracle 可能會選擇完全不同的優化方式。而實際上，在我們的數據庫上的測試驗證了我們的預測. 以下是在HP 上執行時它們的 explain plan:  　　第一句：  　　已選擇325917行。  　　第二句：  　　顯而易見，第1句沒有使用索引，第2句使用了主鍵索引pk_mytables. FF的巨大影響由此可見一斑。由此想到，我們在寫sql 語句時，如果預先估計一下 FF, 你就幾乎可以預見到 Oracle 會否使用索引。 

關鍵詞標簽: 標題 標簽