Oracle索引大全（以及生產中適用的場景）

文檔結構如下：

前言：

Oracle 官方文檔對索引的描述真是弱透了，對索引的說明就是一坨……，support也沒有很好的資料，下面還是用的官方上的內容經過自己的整理加上網上的資料；至於為什么用索引，以及索引的重要性，相信大家都知曉；如果把數據庫所有的表比如成一本書，那么，索引就是書的目錄，你不可能每一次查看書的內容從第一頁讀到最后一頁，不用目錄吧！！

索引類型：

索引是與表和群集關聯的可選結構，可以使SQL查詢對表執行得更快。正如本手冊中的索引可以幫助您更快地找到信息（沒有索引）一樣，Oracle數據庫索引提供了對表數據的更快訪問路徑。您可以使用索引而無需重寫任何查詢。結果是相同的，但是可以更快地看到它們。

Oracle數據庫提供了幾種索引方案，這些方案提供了互補的性能功能。這些是：

• B樹索引：默認索引和最常見索引
• B樹集群索引：專門為集群定義
• 哈希集群索引：專門為哈希集群定義
• 全局和局部索引：與分區表索引有關
• 反向鍵索引：對Oracle Real Application Clusters應用程序最有用
• 位圖索引：緊湊；最適合具有少量值的列
• 基於函數的索引：包含函數/表達式的預先計算的值
• 域索引：特定於應用程序或盒帶。

索引在邏輯上和物理上獨立於關聯表中的數據。作為獨立的結構，它們需要存儲空間。您可以創建或刪除索引，而不會影響基表，數據庫應用程序或其他索引。當您插入，更新和刪除關聯表的行時，數據庫會自動維護索引。如果刪除索引，所有應用程序將繼續運行。但是，訪問以前索引的數據可能會更慢。

一、  管理索引的准則：

• 插入表數據后創建索引
• 適合創建索引的場景
• 性能的訂單索引列
• 限制每個表的索引數
• 刪除不再需要的索引
• 估計索引大小並設置存儲參數
• 指定每個索引的表空間
• 考慮並行化索引創建
• 考慮使用NOLOGGING創建索引
• 考慮合並或重建索引的成本和收益
• 在禁用或刪除約束之前要考慮成本

 

 

插入表數據后創建索引

通常使用SQL * Loader或導入實用程序將數據插入或加載到表中。

適合創建索引的場景

索引適用場景：

使用以下准則確定何時創建索引：

• 如果您經常要檢索大表中少於15％的行，則創建索引。根據表掃描的相對速度以及行數據相對於索引鍵的分布方式，百分比差異很大。表掃描越快，百分比越低；行數據越聚類，百分比越高。
• 為了提高多個表的聯接性能，將索引列用於聯接。

• 主鍵和唯一鍵自動具有索引。
• 小表不需要索引。如果查詢花費的時間太長，則表可能已從小變大。

 

適用於索引的列（官方說的也不一定准確有的）

一些列很適合索引。具有以下一個或多個特征的列可作為索引的候選：

• 列中的值相對唯一。
• 值的范圍很廣（適用於常規索引）。
• 值的范圍很小（適用於位圖索引）。
• 該列包含許多空值，但查詢通常選擇具有值的所有行。在這種情況下，請使用以下短語：

      WHERE COL_X > -9.99 * power(10,125) ;

WHERE COL_X IS NOT NULL ;

這是因為第一個使用索引作為索引COL_X（假設它COL_X是一個數字列）。

實驗如下：

create table test as select * from dba_objects;

update test set  OBJECT_ID=rownum;

 

 

 

update test set  OBJECT_ID=null where OBJECT_ID >10000;

commit;

create index id_idx on test(OBJECT_ID) online;

begin

    dbms_stats.gather_table_stats('sys','test',cascade=>true);

    end;

     /

set autotrace traceonly

select * from test where object_id is null;

 

 

 

其實這個官方說的不是特別正確（IS NOT NULL這個范圍還是在15%以內，所以還是走的索引）

 

以下是范圍超過15%

 

 

 

 

 

begin

    dbms_stats.gather_table_stats('sys','t1',cascade=>true);

    end;

     /

 

 

 

其實這個官方說的不是特別正確（IS NOT NULL這個范圍還是在50%以內>15%，所以走的全表掃描）

 

索引列性能

CREATE INDEX語句中列的順序可能會影響查詢性能。通常，首先指定最常用的列。

 

如果要創建跨越，加快查詢列單索引訪問，例如col1，col2和col3; 然后，訪問just col1或just col1和訪問的查詢col2也將加快。但是訪問了just col2，just col3或just col2並且col3不使用索引的查詢。

 

限制每個表的索引數

 

一個表可以有任意數量的索引。但是，索引越多，修改表的開銷就越大。具體來說，當插入或刪除行時，表上的所有索引也必須更新。此外，更新列時，必須更新包含該列的所有索引。

 

因此，在從表中檢索數據的速度與更新表的速度之間需要權衡。例如，如果一個表主要是只讀的，那么擁有更多的索引將很有用。但是如果表被大量更新，則最好使用較少的索引。

 

刪除不再需要的索引

如果出現以下情況，請考慮刪除索引：

• 它不會加快查詢速度。該表可能很小，或者表中可能有很多行，但索引條目卻很少。
• 您的應用程序中的查詢不使用索引。
• 索引必須在重建之前被刪除。

估計索引大小並設置存儲參數

在創建索引之前估算索引的大小可以促進更好的磁盤空間規划和管理。您可以使用索引的組合估計大小以及表，撤消表空間和重做日志文件的估計，來確定保存目標數據庫所需的磁盤空間量。根據這些估計，您可以做出正確的硬件購買和其他決策。

使用單個索引的估計大小可以更好地管理索引使用的磁盤空間。創建索引后，可以設置適當的存儲參數並提高使用該索引的應用程序的I / O性能。例如，假設您在創建索引之前先估計其最大大小。如果隨后在創建索引時設置存儲參數，則會為表數據段分配較少的擴展區，並且所有索引數據都存儲在磁盤空間的相對連續的部分中。這減少了涉及該索引的磁盤I / O操作所需的時間。

單個索引條目的最大大小約為數據塊大小的一半。

可以通過以下兩種方式來設置為索引創建的索引段的存儲參數，該索引段用於執行主鍵或唯一鍵約束：

• 在or 語句的ENABLE... USING INDEX子句中CREATE TABLEALTER TABLE
• 在聲明的STORAGE子句中ALTER INDEX

 

指定每個索引的表空間

可以在任何表空間中創建索引。可以在與其索引的表相同或不同的表空間中創建索引。如果為表及其索引使用相同的表空間，則執行數據庫維護（如表空間或文件備份）或確保應用程序可用性會更方便。所有相關數據始終在線。

與在同一表空間中存儲表和索引相比，對表及其索引使用不同的表空間（在不同的磁盤上）會產生更好的性能。減少磁盤爭用。但是，如果您對一個表使用不同的表空間，並且該表的索引一個表空間處於脫機狀態（包含數據或索引），則不能保證引用該表的語句可以正常工作。

考慮並行化索引創建

您可以並行化索引創建，與並行化表創建相同。因為多個進程一起創建索引，所以與單個服務器進程按順序創建索引相比，數據庫可以更快地創建索引。

並行創建索引時，每個查詢服務器進程分別使用存儲參數。因此，在索引創建期間，使用初始化的5M值和12的並行度創建的索引會消耗至少60M的存儲空間。

 

 

考慮使用NOLOGGING創建索引

通過NOLOGGING在CREATE INDEX語句中指定，可以創建索引並生成最少的重做日志記錄。

創建索引NOLOGGING具有以下好處：

• 空間保存在重做日志文件中。
• 創建索引所需的時間減少了。
• 並行創建大索引可提高性能。

通常，創建的較大索引的相對性能改進比較LOGGING小的索引要大。創建小的索引LOGGING對創建索引所花費的時間幾乎沒有影響。但是，對於較大的索引，性能改進可能非常顯着，尤其是當您同時並行化索引創建時。

考慮合並或重建索引的成本和收益

大小不正確或增長增加會產生索引碎片。要消除或減少碎片，您可以重建或合並索引。但是在執行任何一項任務之前，請權衡每種選擇的成本和收益，然后選擇最適合您情況的選擇。是與重建和合並索引相關的成本和收益的比較。

 

 

 

 

B樹索引葉子塊以供重用的情況下，可以使用以下語句合並這些葉子塊：

ALTER INDEX vmoore COALESCE;

 

 

 

在禁用或刪除約束之前要考慮成本

由於唯一鍵和主鍵具有關聯的索引，因此在考慮禁用還是刪除UNIQUE或PRIMARY KEY約束時，應考慮刪除和創建索引的成本。如果UNIQUE鍵或PRIMARY KEY約束的關聯索引非常大，則可以通過啟用約束而不是刪除並重新創建大索引來節省時間。您還可以選擇在刪除或禁用UNIQUE或PRIMARY KEY約束時明確指定要保留或刪除索引。

 

基於功能的創建索引

創建一個在線索引（生產）

生產中比如說有一張大的分區表需要創建索引，要是直接執行create index 下去，估計直接就HANG住了，索引需要使用online關鍵字，在線創建和重建索引。可以在基礎表上建立或重建索引的同時更新基礎表，可以在建立索引的同時執行DML操作，但不允許DDL操作。在線創建或重建索引時，不支持並行執行。如下：

CREATE INDEX emp_name ON emp（mgr，emp1，emp2，emp3）online;

 

注意：

完成在線索引構建所需的時間與表的大小和並發執行的DML語句的數量成正比。因此，最好在DML活動較少時開始在線索引構建。

 

創建索引時收集附帶統計信息（生產）

Oracle數據庫為您提供了在創建或重建索引期間以極少的資源成本收集統計信息的機會。這些統計信息存儲在數據字典中，供優化器在選擇執行SQL語句的計划時繼續使用。以下語句：

CREATE INDEX hr.last_name_idx ON hr.employees(LAST_NAME) ONLINE

     COMPUTE STATISTICS;

大表的時候可以執行在線創建並收集統計信息

 

創建一個鍵壓縮索引

使用鍵壓縮創建索引使您可以消除重復出現的鍵列前綴值。

鍵壓縮將索引鍵分為前綴和后綴條目。通過在索引塊的所有后綴條目之間共享前綴條目來實現壓縮。這種共享可以節省大量空間，使您可以為每個索引塊存儲更多鍵，同時提高性能。

密鑰壓縮在以下情況下很有用：

• 您具有一個非唯一索引，ROWID該索引后面附加了唯一索引。如果您在此處使用鍵壓縮，則重復的鍵將作為前綴條目存儲在索引塊中，而不包含ROWID。其余的行成為僅包含的后綴條目ROWID。
• 您有一個唯一的多列索引。

您可以使用COMPRESS子句啟用密鑰壓縮。還可以指定前綴長度（作為鍵列的數量），以標識如何將鍵列分為前綴和后綴條目。例如，以下語句壓縮索引葉子塊中重復出現的鍵：

 

CREATE INDEX  emp_ename ON emp(ename)

   TABLESPACE users

   COMPRESS 1;

解壓：

ALTER INDEX emp_ename REBUILD NOCOMPRESS;

 

創建不可見索引

從版本11 g開始，可以創建不可見索引。一個無形的指數是由優化忽略，除非你明確地設定一個指標OPTIMIZER_USE_INVISIBLE_INDEXES初始化參數TRUE在會話或系統級。使索引不可見是使其無法使用或刪除它的替代方法。使用不可見索引，您可以執行以下操作：

• 在刪除索引之前，請測試刪除索引。
• 對應用程序的某些操作或模塊使用臨時索引結構，而不會影響整個應用程序。

與不可用的索引不同，在DML語句期間維護不可見的索引。

要創建不可見索引，請CREATE INDEX在INVISIBLE子句中使用SQL語句。以下語句創建一個以表emp_ename的ename列命名的不可見索引emp：

CREATE INDEX emp_ename ON emp(ename)

      TABLESPACE users

      STORAGE (INITIAL 20K

      NEXT 20k

      PCTINCREASE 75)

      INVISIBLE;

 

 

二、  創建索引語法

1.      索引分類：

Oracle數據庫提供了幾種索引方案，這些方案提供了互補的性能功能。這些是：

• B樹索引：默認索引和最常見索引
• B樹集群索引：專門為集群定義
• 哈希集群索引：專門為哈希集群定義
• 全局和局部索引：與分區表和索引有關
• 反向鍵索引：對Oracle Real Application Clusters應用程序最有用
• 位圖索引：緊湊；最適合具有少量值的列
• 基於函數的索引：包含函數/表達式的預先計算的值
• 域索引：特定於應用程序或盒帶。

以下是網絡上找到的相關分類

邏輯上：

Single column 單行索引

Concatenated 多行索引

Unique 唯一索引

NonUnique 非唯一索引

Function-based函數索引

Domain 域索引

 

物理上：

Partitioned 分區索引

NonPartitioned 非分區索引

B-tree

Normal 正常型B樹

Rever Key 反轉型B樹

Bitmap 位圖索引

全文索引

本節介紹如何創建索引。要在您自己的架構中創建索引，必須至少滿足以下條件之一：

• 要建立索引的表或集群在您自己的模式中。
• 您INDEX對要編制索引的表具有特權。
• 您具有CREATE ANY INDEX系統特權。

要在另一個架構中創建索引，必須滿足以下所有條件：

• 您具有CREATE ANY INDEX系統特權。
• 其他模式的所有者對表空間有一個配額，以包含索引或索引分區或UNLIMITED TABLESPACE系統特權。

2.      創建btree索引

語法如下：

 

 

 

create table table_index as select * from dba_objects;

UPDATE table_index SET object_id=ROWNUM;

下面是創建bitree索引

create index OBJECT_ID_idx on table_index(OBJECT_ID);

 

btree應用場景：

非常適合數據重復率低的字段,例如ID等唯一性約束這種字段。

 

3.      創建btmap索引

create bitmap index OBJECT_TYPE_idx on table_index(OBJECT_TYPE);

bitmap應用場景：

重復率很高的鍵值；位圖索引由於只存儲鍵值的起止Rowid和位圖，占用的空間非常少，且在bitmap index中一個dml操作，影響的是一個位圖段（同一鍵值）。嚴重影響頻繁的DML（極其容易造成會話hang住），造成死鎖。

 

限制位 圖索引受到以下限制：

• BITMAP創建全局分區索引時無法指定。
• 您不能在索引組織的表上創建位圖二級索引，除非索引組織的表具有與其關聯的映射表。
• 您不能同時指定UNIQUE和BITMAP。
• 您無法指定BITMAP域索引。
• 一個位圖索引最多可以包含30列。

 

 

4.      創建域索引（domain索引即全文索引）

 要在自己的架構中創建域索引，除了創建常規索引的先決條件外，您還必須對索引類型具有EXECUTE對象特權。如果要在另一個用戶的架構中創建域索引，則索引所有者還必須對索引EXECUTE類型及其基礎實現類型具有對象特權。在創建域索引之前，應首先定義索引類型。

b-tree,bitmap無法發揮作用的場景，like '%string%'模糊匹配；占用過大的磁盤空間（全文索引大約是原表的1.5倍，重建成本很高）、維護成本高。

Oracle10g 里面支持四種類型的索引：

context、ctxcat、ctxrule、ctxxpath 

 

 

 

以下只用context索引。

CREATE INDEX text_idx ON table_index(object_name) indextype is ctxsys.context;

 

 

 

SELECT * FROM TABLE_INDEX WHERE contains(OBJECT_NAME,'ACCOUNT') >1;

查看執行計划：

 

 

 

查看執行計划，走的是domian全文索引，如果是其它用戶，在建立文本索引的時候，需要授權（詳細步驟不演練了）。

 

5.   創建cluster(集群)索引

創建語法如下：

 

 

 

 

 

 

一下是例子：

由於這個不是普通便（堆表），我們一般使用的普通便是堆表，而集群索引是基於cluster表的創建cluster語句：

創建集群：

示例創建cluster

下面的語句創建一個以personnelcluster key column 命名的集群department，512字節的集群大小和存儲參數值：

CREATE CLUSTER personnel

   (department NUMBER(4)) SIZE 512  STORAGE (initial 100K next 50K);

示例創建cluster index在cluster key上

CREATE INDEX idx_personnel ON CLUSTER personnel;

將表添加到集群：

CREATE TABLE dept_10

   CLUSTER personnel (department_id)

   AS SELECT * FROM hr.employees WHERE department_id = 10;

 

CREATE TABLE dept_20

   CLUSTER personnel (department_id)

   AS SELECT * FROM hr.employees WHERE department_id = 20;

 

 

 

要說cluster使用環境，只能是cluster 表，以下是什么環境使用cluster表：

 

如果一組表有一些共同的列，則將這樣一組表存儲在相同的數據庫塊中;聚簇還表示把相關的數據存儲在同一個塊上。利用聚簇，一個塊可能包含多個表的數據。概念上就是如果兩個或多個表經常做連接操作，那么可以把需要的數據預先存儲在一起。聚簇還可以用於單個表，可以按某個列將數據分組存儲。

 

什么時候不應該使用聚簇：

 

　　1) 如果預料到聚簇中的表會大量修改：必須知道，索引聚簇會對DML的性能產生某種負面影響(特別是INSERT語句)。管理聚簇中的數據需要做更多的工作。

 

　　2) 如果需要對聚簇中的表執行全表掃描：不只是必須對你的表中的數據執行全面掃描，還必須對(可能的)多個表中的數據進行全面掃描。由於需要掃描更多的數據，所以全表掃描耗時更久。

 

　　3) 如果你認為需要頻繁地TRUNCATE和加載表：聚簇中的表不能截除。這是顯然的，因為聚簇在一個塊上存儲了多個表，必須刪除聚簇表中的行。

 

　　因此，如果數據主要用於讀(這並不表示“從來不寫”;聚簇表完全可以修改)，而且要通過索引來讀(可以是聚簇鍵索引，也可以是聚簇表上的其他索引)，另外會頻繁地把這些信息聯結在一起，此時聚簇就很適合。

 

6.      創建hash集群索引

跟5比較類似：

CREATE CLUSTER language (cust_language VARCHAR2(3))

   SIZE 512 HASHKEYS 10

   STORAGE (INITIAL 100k next 50k);

 

CREATE CLUSTER address

   (postal_code NUMBER, country_id CHAR(2))

   HASHKEYS 20

   HASH IS MOD(postal_code + country_id, 101);

 

單個hash案例：

CREATE CLUSTER cust_orders (customer_id NUMBER(6))

   SIZE 512 SINGLE TABLE HASHKEYS 100;

 

7.      全局和局部索引(分區表)

這個應該用過oracle 分區表的都知道把，我的專門說明全局索引和本地索引的博客地址：

https://www.cnblogs.com/hmwh/p/11964022.html（主要是組合索引）

 

8.      反向鍵索引（mysql也有）

1.反向索引應用場合

1）發現索引葉塊成為熱點塊時使用

通常，使用數據時（常見於批量插入操作）都比較集中在一個連續的數據范圍內，那么在使用正常的索引時就很容易發生索引葉子塊過熱的現象，嚴重時將會導致系統性能下降。

2）在RAC環境中使用

當RAC環境中幾個節點訪問數據的特點是集中和密集，索引熱點塊發生的幾率就會很高。如果系統對范圍檢索要求不是很高的情況下可以考慮使用反向索引技術來提高系統的性能。因此該技術多見於RAC環境，它可以顯著的降低索引塊的爭用。

 

2.使用反向索引的優點

最大的優點莫過於降低索引葉子塊的爭用，減少熱點塊，提高系統性能。

 

3.使用反向索引的缺點

由於反向索引結構自身的特點，如果系統中經常使用范圍掃描進行讀取數據的話（例如在where子句中使用“between and”語句或比較運算符“>”“<”等），那么反向索引將不適用，因為此時會出現大量的全表掃描的現象，反而會降低系統的性能。

 

create index  on <TABLE_NAME> (<COLUMN_NAME>, <COLUMN_NAME>)

REVERSE

create index emp_reverse_idx on scott.EMP (mgr) REVERSE;

SELECT * FROM scott.EMP WHERE mgr =7902;

 

 

 

 

SELECT * FROM scott.EMP WHERE mgr > 7902;

當執行范圍查詢的時候，走的是全表掃描。

 

 

 

 

 

9.      函數的索引

基於函數的索引有助於查詢限定函數或表達式返回的值的查詢。函數或表達式的值已預先計算並存儲在索引中。

除了創建常規索引的前提條件之外，如果索引基於用戶定義的函數，則必須標記這些函數。另外，如果基於函數的索引由另一個用戶擁有，則僅具有對這些用戶定義函數使用的對象特權。

此外，要使用基於函數的索引：

• 創建索引后必須分析該表。
• 必須確保查詢不需要NULL來自索引表達式的任何值，因為NULL值未存儲在索引中。

索引標記為無效，必須使用該ANALYZE INDEX...VALIDATE STRUCTURE語句來驗證此索引。

比如：

CREATE INDEX EMP_SUM_IDX ON hr.EMPLOYEES (SUBSTR(PHONE_NUMBER, 0, 3));

 

ANALYZE INDEX  EMP_SUM_IDX VALIDATE STRUCTURE； --查看索引是否有效

SELECT * FROM user_indexes WHERE index_name='EMP_SUM_IDX';

SELECT t.FIRST_NAME,SUBSTR(PHONE_NUMBER, 1, 3) FROM hr.EMPLOYEES t WHERE t.FIRST_NAME='Susan';

 

10. 創建基於約束的索引

單獨創建一個唯一索引：

CREATE UNIQUE INDEX dept_unique_index ON dept (dname)

      TABLESPACE indx;

 

創建基於唯一約束的索引：

 

以下案例為1，2，3：

 

CREATE TABLE a (

     a1 INT PRIMARY KEY USING INDEX (create index ai on a (a1)));

 

 

CREATE TABLE b(

     b1 INT,

     b2 INT,

     CONSTRAINT bu1 UNIQUE (b1, b2)

                    USING INDEX (create unique index bi on b(b1, b2)),

     CONSTRAINT bu2 UNIQUE (b2, b1) USING INDEX bi);

 

CREATE TABLE c(c1 INT, c2 INT);

CREATE INDEX ci ON c (c1, c2);

ALTER TABLE c ADD CONSTRAINT cpk PRIMARY KEY (c1) USING INDEX ci;

 

三．  變更索引

索引變更包括以下：

要更改索引，您的架構必須包含索引，或者您必須具有ALTER ANY INDEX系統特權。使用該ALTER INDEX語句，您可以：

• 重建或合並現有索引
• 釋放未使用的空間或分配新的擴展區
• 指定並行執行（或不指定）並更改並行度
• 更改存儲參數或物理屬性
• 指定LOGGING或NOLOGGING
• 啟用或禁用按鍵壓縮
• 將索引標記為不可用
• 使索引不可見
• 重命名索引
• 開始或停止監視索引使用情況

其它的應該比較常見，不常見的是最后一個，開啟或者停止監視索引使用情況。

ALTER INDEX index MONITORING USAGE;

比如：

ALTER  INDEX  hr.EMP_DEPARTMENT_IX  MONITORING USAGE;

select * from V$OBJECT_USAGE;

 

ALTER INDEX index NOMONITORING USAGE;

ALTER  INDEX  hr.EMP_DEPARTMENT_IX  NOMONITORING USAGE;

select * from V$OBJECT_USAGE;

可以在視圖中查詢正在監視的索引，以查看是否已使用該索引。該視圖包含一列，其值是或，取決於在監視的時間段內是否已使用索引。該視圖還包含監視周期的開始和停止時間，

每次指定MONITORING USAGE，V$OBJECT_USAGE都會為指定的索引重置視圖。先前的使用信息將被清除或重置，並記錄新的開始時間。當您指定時NOMONITORING USAGE，將不執行進一步的監視，並且將記錄監視時間的結束時間。在ALTER INDEX...MONITORING USAGE發出下一條語句之前，視圖信息將保持不變。

 

四．  索引數據字典視圖

沒有設計到分區表的相關索引

視圖	注釋
DBA_INDEXES ALL_INDEXES USER_INDEXES	DBA視圖描述了數據庫中所有表的索引。ALL視圖描述了用戶可訪問的所有表上的索引。USER視圖僅限於用戶擁有的索引。這些視圖中的某些列包含由DBMS_STATS包或ANALYZE語句生成的統計信息。
DBA_IND_COLUMNS ALL_IND_COLUMNS USER_IND_COLUMNS	這些視圖描述了表上的索引列。這些視圖中的某些列包含由DBMS_STATS包或ANALYZE語句生成的統計信息。
DBA_IND_EXPRESSIONS ALL_IND_EXPRESSIONS USER_IND_EXPRESSIONS	這些視圖描述了表上基於函數的索引的表達式。
DBA_IND_STATISTICS ALL_IND_STATISTICS USER_IND_STATISTICS	這些視圖包含索引的優化器統計信息。
INDEX_STATS	存儲來自最后一條ANALYZE INDEX...VALIDATE STRUCTURE語句的信息。
INDEX_HISTOGRAM	存儲來自最后一條ANALYZE INDEX...VALIDATE STRUCTURE語句的信息。
V$OBJECT_USAGE	包含該ALTER INDEX...MONITORING USAGE功能產生的索引使用情況信息。

 

 

資料來自官方：

https://docs.oracle.com/cd/B28359_01/server.111/b28310/indexes001.htm#ADMIN11709

https://docs.oracle.com/database/121/SQLRF/statements_5013.htm#SQLRF01209

 

五．  生產中的索引處理

這個是我這段時間補寫的，適當的說一下，很多面試中的問題或者生產會遇到的坑，比如說什么時候分區表什么時候使用全局索引，什么時候使用本地索引，以及大表怎么創建索引，以及分區表的分區進行truncate,drop,spit等操作時，全局索引失效怎么處理保證不影響業務性能！

1.大表建索引

建索引是一個表鎖的過程，如果該表是頻繁dml操作，建議 create  index  index_name on table_name online; 操作不影響update等操作

2.分區表什么時候用全局索引，什么時候用本地索引

其實很多網上的說的不太好，一來就是執行計划，什么邏輯讀一致性獲取等；

這個先是要基於業務需求，比如說我要再一張大的分區表查詢用戶名，但是不知道該用戶創建的時間，顯然是全表找用戶名，這樣分區表的分區段本地索引就不適用了（分區范圍掃描用不到，全表掃），這種只能用全局索引；

如果我需要查詢這兩天某個值多少，即在某段時間內查找分區范圍掃描，能夠用上這段分區時間的本地建的索引段，這種適合本地索引，即分區的范圍了在利用本地索引，如果這種用全局索引，時間分區就沒有任何意義，全表索引快速掃描，性能大大折扣。

3.分區表drop/truncate/spit等操作，全局索引失效怎么辦？

生產上24*7全局索引失效會引起業務報錯甚至是hang住。

在我另外一篇博客也提到，自動更新索引（尤其是全局索引）

即 alter  table table_name drop/truncate/spit partition/subpartiton (partition/subpartition)_name  update (global) indexes;

他是直接在基表操作，不影響DML以及全局索引狀態。

還有比較重要的是：

create unique index UK_INT_BET_DETAIL_test on INT_BET_DETAIL_test (RPT_DATE, ID)

nologging local online;  可以這樣子創建本地唯一索引()不一定非得創建全局索引主鍵)；

 

 

有關分區表和索引，我還有一篇文章：

https://www.cnblogs.com/hmwh/p/11964022.html