1.index需要儲存空間和I/O操作。
2.index的目的是加快select的速度的。
3.insert,update,delete數據oracle會同時對索引進行相應的調整，因此會增加一定的消耗。
4.使用index一定能加快select速度嗎？不是的，數據少和巨大時index會影響select的速度，因此如果查詢速度可以滿足，就不要建index。
5．Index 對null 無效。
分類：
一、從物理角度
1. partitioned or nonpartitioned : 分區或不分區索引。分區索引用於分區表。
2.B-tree(平衡樹) : normal or reverse key 正常和倒序索引。
oracle默認索引方式，平衡樹形索引，在葉子節點上有雙向鏈表，加快索引定位速度，oracle有一定的優化，可以根據鏈表直接定位記錄，而不走樹，綜合使用提高速度。見圖1和圖2。
圖1
圖2
3.bitmap(位圖) ：用二進制的0、1來構建索引，在進行or操作時非常快, 但要注意bitmap對於併發操作時，改一條會鎖了很多記錄，因爲所有的記錄在一個索引條目上，所以修改或增加時會一起鎖定，見圖3.
圖3
區別和使用場景
|
B-tree索引 |
Bitmap 索引 |
|
Suitable for high-cardinality columns（記錄對應的列重複的值較少，如主鍵，姓名等 ）。 |
Suitable for low-cardinality columns(用在記錄相同的值較多的列上，如果性別只有兩種值：男和女)。 |
|
Updates on keys relatively inexpensive （在做updated時，b-tree只消耗很少的資源）。 |
Updates to key columns very expensive （在做updated時，bitmap的消耗是昂貴的）。 |
|
Inefficient for queries using OR predicates（where子句中 or條件較多時速度較慢） |
Effcient for queries using OR predicates （where子句中 or條件較多時速度非常快） |
|
Useful for OLTP（記錄頻繁的insert和update,查詢相對較少的系統）。 |
Useful for data warehousing （OLIP）數據倉庫，查詢系統等較少做數據修改的系統。 |
二、邏輯角度：
1.single column or concatenated單索引和組合索引。
2.unique or nonunique: 唯一索引和非唯一索引。
3.function-based: 基於函數的索引，把一些where條件作爲函數。
4.domain： 數據庫以外的索引，如文件等。
三、創建index時的注意事項：
1.balance query and DML needs: 索引的目的是爲了提高查詢速度，但它會加重DML的負擔。
2.place in separate tablespace: 索引和表應該放在不同的表空間，如果把索引和表放在同一個空間，會引起競爭，因爲在讀取一個表時，記錄和索引是同時讀取，修改也同步進行的。
3.use uniform extent sizes:Multipes of five blocks or minimum extent size for tablespace. 索引空間是extent是大小應該是5 blocks的倍數，因爲oracle是一次讀出5個blocks，如果你的extends是6，就會造成2次I/O操作。
4. consider nologging for large indexes： 在創建索引時可以關閉索引對應的redo 日誌，提高速度，因爲索引和數據不同，如果索引創建時出意外，數據還在，就再創建一次好了。
5.INITRANS should generally be higher on indexes than on the corresponding tables：INITRANS 參數比對應的表的值大些，因爲索引也是已表記錄的方式保存的，但索引大大小於表的記錄，所以一個block中存儲的索引記錄就大大多於表在一個block中的記錄，加大INITRANS可以增加在一個block中的事務的併發數，就提高了效率。
6.rebuilding indexes:如果刪除一條記錄，對應的索引僅僅是做了邏輯刪除，只有一個block中的全部索引都被標識爲邏輯刪除，orcle纔會真正的回收block, 這時這個block才能被再次利用，在表的記錄做update時，index是先做了邏輯刪除，然後再爲該記錄新建一個索引的，所以表在頻繁的增刪改後，就會造成index對應的block不完整，和系統碎片的情況是一致的，造成空間浪費，加大index的I/O，影響性能。而rebuilding indexes就可以回收原來的，重新構建一個高效的索引，但重構時會鎖表。
語法： alter index index_name rebuild;
7． coalescing indexes: 整理索引碎片，效率高，不鎖表。
語法：Alter index index_name coalesce;
四．管理索引
1.分析索引：
1) select * from user_objects where object_type='INDEX'
2）analyze index PK_T_TICKET validate structure;
3）select * from index_stats;
|
HEIGHT（b-tree的高度） |
BLOCKS（索引有多少塊） |
NAME（索引名） |
LF_ROWS（記錄數） |
DEL_LF_ROWS（刪除記錄數） |
|
2 |
256 |
PK_T_TICKET |
82775 |
792 |
當 DEL_LF_ROWS/ LF_ROWS>15%時應進行 索引重建或 索引碎片整理。
2.drop 索引：當屁量導入大量數據時，索引會影響導入速度。可以現在drop掉，導入後再重建索引。
3.監控索引：
1）設置監控那個索引 alter index pk_t_ticket monitoring usage;
2）查看該索引用沒有使用select * from v$object_usage
3）select count(1) from pk_t_ticket;
4) 查看該索引用沒有使用select * from v$object_usage
5)關閉監控 alter index pk_t_ticket nomonitoring usage;
監控一個月就大概可以知道那些是無用的索引了。
6） 查詢索引的詳細信息 ： select * from all_ind_columns where index_name='PK_T_TICKET' .那個表的那個列上有索引及詳細信息。
copy from : http://dolphin-ygj.javaeye.com/blog/543906