41.oracle索引，分析索引，索引碎片整理

概述

索引分為B樹索引和位圖索引。我們主要研究B樹索引，B樹索引如下圖（圖片源自網絡）：

　　索引是與表相關的一個可選結構，在邏輯上和物理上都獨立於表數據，索引能優化查詢，不能優化DML，oracle自動維護索引，頻繁的DML操作反而會引起大量的索引維護。

　　如果sql語句僅僅訪問被索引的列，那么數據庫只需從索引中讀取數據，而不會讀取表；如果該語句還要訪問未被索引的列，那么數據庫會使用rowid來查找表中的行，通常，為檢索表數據，數據庫以交換方式先讀取索引塊，然后讀取對應的表。

　　索引的目的是減少IO，

1. 大表，返回的行數<5%
2. 經常使用where子句查詢的列
3. 離散度高的列
4. 更新鍵值代價低
5. 邏輯AND、OR效率高
6. 查看索引建在哪表哪列
   select * from user_indexes;
   select * from user_ind_columns;

索引的使用

1. 唯一索引
   create unique index empno_idx on emp(empno);
2. 一般索引
   create index empno_idx on emp(empno);
3. 組合索引
   create index job_deptno_idx on emp(job,deptno);
4. 函數索引：查詢時必須用到這個函數才會使用到。
   create index fun_idx on emp(lower(ename));
5. 。。。

索引問題

查看執行計划：set autotrace traceonly explain；

　　索引碎片問題：由於基表做DML操作，導致索引表塊的自動更改操作，尤其是基表的delete操作會引起index表的index_entries的邏輯刪除，注意只有當一個索引塊中的全部index_entry都被刪除了，才會把這個索引塊刪除，索引對基表的delete、insert操作都會產生索引碎片問題。

　　在oracle文檔中並沒有清晰的給出索引碎片的量化標准，oracle建議通過segment advisor（片段顧問）解決表和索引的碎片問題（后面的課程會提及），如果你想自行解決，可以通過查看 index_stats視圖，當以下三種情形之一發生時，說明積累的碎片應該整理了（經驗之談）

1. height >= 4 （概述中圖示索引樹的高度是3）
2. pct_used < 50%
3. del_lf_rows/lf_row > 0.2

實操：

先建表，建索引

然后插入1000000條數據

 

分析索引：analyse index t_idx validate structure;

查看分析結果：select name,height,pct_used,del_lf_rows/lf_rows from index_stats;

 

然后我們來破壞一下索引，重新查看一下分析結果

可以看到最后一個指標變了。說明產生一些碎片了。那么需要進行整理：

可見最后一個指標正常了（低於0.2）。