oracle数据库关于索引建立及使用的详细介绍

索引的说明

索引是与表相关的一个可选结构，在逻辑上和物理上都独立于表的数据，索引能优化查询，不能优化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;

索引结构

oracle索引分为两大类结构：

B树索引结构<balance>

类似于字典查询，最后到leaf block ，存的是数据rowid和数据项

1.叶块之间使用双向链连接，为了可以范围查询。
2.删除表行时，索引叶块也会更新，但只是逻辑更改，并不做物理的删除叶块。
3.索引叶块不保存表行键值null的信息。

位图索引结构<bitmap>

在oracle中是根据rowid来定位记录的，因此，我们需要引入start rowid和end rowid，通过start rowid ，end rowid 和二进制位的偏移，我们就可以非常快速的计算出二进制位所代表的表记录rowid。位图索引的最终逻辑结构如下图：

我们称每一单元的<key ,startrowid,end rowid,bitmap>为一个位图片段。当我们修改某一行数据的时候，我们需要锁定该行列值所对应的位图片段，如果我们进行的是更新操作，同时还会锁定更新后新值所在的位图片段。例如我们将列值从01修改为03，就需要同时锁定01和03位图片段，此时如果有其他用户需要修改与01或者03关联的表记录上的索引字段，就会被阻塞，因此位图索引不适合并发环境，在并发环境下可能会造成大量事务的阻塞。
我们一般在表数据离散度比较低的时候使用位图索引，如t_doctor的empno值重复分布的比较多，则离散度比较低：create bitmap index job_bitmap on t_doctor(empno)

建立索引的方式

1.唯一索引：键值不重复

create unique index doctor_index on t_doctor(empno)

drop indexdoctor_index

2.一般索引：键值可重复

create index doctor_index on t_doctor(empno)

drop indexdoctor_index

3.复合索引：绑定了多个列

create index doctor_index ont_doctor(empno，job)

drop indexdoctor_index

4.反向索引：为避免平衡树索引热块，如t_doctor表中empno开头都是“7”，这样构建索引树的时候，很可能会把所有数据分配到一个块里，使用反向索引，避免此类问题，使索引树分布均匀

create index doctor_index ont_doctor(empno) reverse

drop indexdoctor_index

5.函数索引：查询时必须用到这个函数，才会使用到

create index func_index ont_doctor(lower(empno))

--select * from t_doctor where lower(empno) = 'lina'

drop indexfunc_index

6.压缩索引：不常用

create index doctor_index ont_doctor(empno) compress

drop indexdoctor_index

7.升序降序索引：

create index doctor_index ont_doctor(empno desc, job asc)

drop indexdoctor_index

索引碎片问题

由于对基表做DML操作，导致索引表块的自动更改操作，尤其是基表的delete操作会引起index表的index_entries的逻辑删除，注意只有当一个索引块中的全部index_entry都被删除了，才会把这个索引块删除，索引对基表的delete、insert操作都会产生索引碎片问题。

在Oracle文档里并没有清晰的给出索引碎片的量化标准,Oracle建议通过Segment Advisor(段顾问）解决表和索引的碎片问题，如果你想自行解决，可以通过查看index_stats视图，当以下三种情形之一发生时，说明积累的碎片应该整理了（仅供参考）。

查看执行计划：set autotrace traceonly explain;

分析索引列：

analyze index ind_1 validate structure;

select name,HEIGHT,PCT_USED,DEL_LF_ROWS/LF_ROWS from index_stats;

HEIGHT >=4 


 PCT_USED< 50% 


DEL_LF_ROWS/LF_ROWS>0.2

alter index ind_1 rebuild [online] [tablespace name];