oracle索引,分析索引,索引碎片整理
41.oracle索引,分析索引,索引碎片整理
概述
索引分為B樹索引和點陣圖索引。我們主要研究B樹索引,B樹索引如下圖(圖片源自網路):
索引是與表相關的一個可選結構,在邏輯上和物理上都獨立於表資料,索引能優化查詢,不能優化DML,oracle自動維護索引,頻繁的DML操作反而會引起大量的索引維護。
如果sql語句僅僅訪問被索引的列,那麼資料庫只需從索引中讀取資料,而不會讀取表;如果該語句還要訪問未被索引的列,那麼資料庫會使用rowid來查詢表中的行,通常,為檢索表資料,資料庫以交換方式先讀取索引塊,然後讀取對應的表。
索引的目的是減少IO,
- 大表,返回的行數<5%
- 經常使用where子句查詢的列
- 離散度高的列
- 更新鍵值代價低
- 邏輯AND、OR效率高
- 檢視索引建在哪表哪列
select * from user_indexes;
select * from user_ind_columns;
索引的使用
- 唯一索引
create unique index empno_idx on emp(empno); - 一般索引
create index empno_idx on emp(empno); - 組合索引
create index job_deptno_idx on emp(job,deptno); - 函式索引:查詢時必須用到這個函式才會使用到。
create index fun_idx on emp(lower(ename)); - 。。。
索引問題
檢視執行計劃:set autotrace traceonly explain;
索引碎片問題:由於基表做DML操作,導致索引表塊的自動更改操作,尤其是基表的delete操作會引起index表的index_entries的邏輯刪除,注意只有當一個索引塊中的全部index_entry都被刪除了,才會把這個索引塊刪除,索引對基表的delete、insert操作都會產生索引碎片問題。
在oracle文件中並沒有清晰的給出索引碎片的量化標準,oracle建議通過segment advisor(片段顧問)解決表和索引的碎片問題(後面的課程會提及),如果你想自行解決,可以通過檢視 index_stats檢視,當以下三種情形之一發生時,說明積累的碎片應該整理了(經驗之談)
- height >= 4 (概述中圖示索引樹的高度是3)
- pct_used < 50%
- 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)。