爱华网Single column 单行索引
Concatenated 多行索引
Unique 唯一索引
NonUnique 非唯一索引
Function-based函数索引
Domain 域索引
物理上：
Partitioned 分区索引
NonPartitioned 非分区索引
B-tree：
Normal 正常型B树
Rever Key 反转型B树
Bitmap 位图索引
索引结构：
B-tree：
适合与大量的增、删、改（OLTP）；
不能用包含OR操作符的查询；
适合高基数的列（唯一值多）
典型的树状结构；
每个结点都是数据块；
大多都是物理上一层、两层或三层不定，逻辑上三层；
叶子块数据是排序的，从左向右递增；
在分支块和根块中放的是索引的范围；
Bitmap:
适合与决策支持系统；
做UPDATE代价非常高；
非常适合OR操作符的查询；
基数比较少的时候才能建位图索引；
树型结构：
索引头
开始ROWID，结束ROWID（先列出索引的最大范围）
BITMAP
每一个BIT对应着一个ROWID，它的值是1还是0，如果是1，表示着BIT对应的ROWID有值；
B*tree索引的话通常在访问小数据量的情况下比较适用，比如你访问不超过表中数据的5%，当然这只是个相对的比率，适用于一般的情况。bitmap的话在数据仓库中使用较多，用于低基数列，比如性别之类重复值很多的字段，基数越小越好。
索引就好象一本字典的目录。凭借字典的目录，我们可以非常迅速的找到我们所需要的条目。数据库也是如此。凭借Oracle数据库的索引，相关语句可以迅速的定位记录的位置，而不必去定位整个表。
虽然说，在表中是否创建索引，不会影响到Oracle数据库的使用，也不会影响数据库语句的使用。这就好像即使字典没有目录的话，用户仍然可以使用它一样。可是，若字典没有目录，那么可想而知，用户要查某个条目的话，其不得不翻遍整本字典。数据库也是如此。若没有建立相关索引的话，则数据库在查询记录的时候，不得不去查询整个表。当表中的记录比较多的时候，其查询效率就会很低。所以，合适的索引，是提高数据库运行效率的一个很好的工具。
不过，并不是说表上的索引越多越好。过之而不及。故在数据库设计过程中，还是需要为表选择一些合适的索引。宁缺勿滥，这是建立索引时的一个遵循标准。在理论上，虽然一个表可以设置无限的索引。但是，数据库管理员需要知道，表中的索引越多，维护索引所需要的开销也就越大。每当数据表中记录有增加、删除、更新变化的时候，数据库系统都需要对所有索引进行更新。故数据库表中的索引绝对不是多多益善。具体来说，在索引建立上，笔者对大家有如下建议。
建议一：在基数小的字段上要善于使用位图索引。
基数是位图索引中的一个基本的定义，它是指数据库表中某个字段内容中不重复的数值。如在员工信息表中的性别字段，一般就只有男跟女两个值，所以，其基数为2;婚姻状况字段的话，则其只有已婚、未婚、离婚三种状态，其基数就为3;民族一览内也是只有有限的几个值。
对于要查询基数小的字段，如现在用户想查找所有婚姻状况为“已婚”的“女性”时，利用位图索引可以提高查询的效率。这主要是因为标准索引是通过在索引中保存排序过的索引列以及对应的ROWID来实现的。若我们在基数小的列上建立标准索引的话，则其会返回大量的记录。
而当我们在创建位图索引的时候，在Oracle会对整个表进行扫描，并且会为索引列的每个取值建立一个位图。若内容相同，则在位图上会以一个相同的数字表示。此时，若这个字段的基数比较小的话，则若需要实现对整个字段的查询的话，效率就会非常的高。因为此时，数据库只要位图中数字相同的内容找出来即可。
除了在数据表某列基数比较小的情况下，采用位图索引外，我们往往在一些特殊的情况下，也会建议采用位图索引。最常见的情况是，在Where限制条件中，若我们多次采用AND或者OR条件时，也建议采用位图索引。因为当一个查询饮用了一些部署了位图索引的列的时候，这些位图可以很方便的与AND或者Or 运算符操作结合以快速的找出用户所需要的记录。
但是，这里要注意，不是在条件语句中包含运算符的时候，采用位图索引都能够提供比较高的效率。一般来说，只有AND 或者OR运算符的时候，位图索引才会比较具有优势。若此时用户采用大于号或者不等于号作为条件语句中的限制条件的时候，则往往采用标准索引具有更大的优势。
所以，笔者在数据库设置中，一般只有在三种情况下才采用位图索引。一是列的基数比较小，而有可能需要根据这些字段的内容查找相关的记录;二是在条件语句中，用到了AND或者OR运算符的时候。除了这两种情况外，最好能够采用其他适合的索引。第三种情况是，需要用到NULL作为查询的限制条件。因为标准查询一般情况下，会忽略所有的NULL值列。也就是说，若需要查询“所有没有身份证号码”的员工的信息的时候，标准索引并不能够起到加速查询速度的作用。此时，就需要采用位图索引。因为位图索引会记录相关的NULL值列信息。
建议二：创建索引的一些限制条件。
并不说，表或者列建立的索引越多越好。相反，索引建的越多，有时会反而会影响数据库运行的整体性能。所以，在建立索引的时候，仍然会有一些限制条件。
一是不要对一些记录内容比较少的表建立索引。在一个应用系统设计的时候，如设计一个ERP系统的数据库，其虽然有几千张表。但是，并不是每张表都有大量记录的。相反，其中有近一半左右的数据表，可能其存储的数据不会超过百条。如员工登陆帐户密码表、企业部门信息表等等。对于这些记录内容比较少的表，我们建立最好不要为其建立索引。无论是表上的，还是字段上，都不要建立索引。
二是若表中的内容比较大，但是，这个表基本上不怎么查询的时候，则只需要在表上建立索引即可;而不需要在字段上建立索引。如现在在ERP系统中，有一张表是“AD_Table”。其存储的是这个数据库中相关表的信息。这张表只有在数据库设计的时候才会用到。故这张表中的记录虽然比较多，但是由于用户用的比较少，所以，一般没有必要为这张表建立列级别上的索引。而直接用表索引来代替。
三是在一些NULL字段上，要根据实际情况来判断是否要建立索引。如现在有一张人事档案的表格，其上面有两个字段，分别为“身份证号码”与“地区”。有时会为了某个原因，企业需要所有员工都在系统中登记他们的身份证号码，以方便他们办工资卡、社会保险等等。所以人事管理可能需要经常的查询系统，看看有没有没有身份证号码的员工信息。此时，就需要利用条件“IS NULL”来查询我们所需要的记录。故为了提高查询效率，若某个记录可能为空，并且经常需要以NULL为条件进行查询的时候，则最好给这个字段添加一个索引，并且最好建立位图索引。相反，若虽然可能会以NULL这个条件作为查询的限制语句，但是，用的不是很多的时候，则就没有必要为其建立索引。
建议三：多表连接查询的索引设计。
如现在有一个人事管理系统。人事经理想知道员工的社保缴纳情况。他需要知道员工的姓名、职务、户籍性质(农民户口跟居民户口费用不一样)、缴纳的情况等等。但是，这些信息包含在不同的表中。因为为了提高数据库的性能，在表中存储的可能只是某些序号，而不是具体的内容。如在社保表中，存储的是员工对应的编号，而不是员工的名字。所以，要得到这份报表的话，就可能需要关联员工基本信息表、公司组织结构表等表格，才能够查询到用户所需要的内容。
为此，就需要利用Join语句，把这些表格关联起来。为了提高数据库的查询效率，这些用来关联的字段，最好能够建立索引。这可以显著的提高查询的速度。
建议四：在表的更新速度与查询速度之间寻求一个平衡点。
众所周知，索引本身并不影响数据库的使用，其主要是为了提高数据库的查询效率。但是，由于当数据库的表中的数据更新的时候，包括记录的增加、删除、更改等等，都会对虽有的索引进行更新。
很明显，索引虽然可以提高查询速度。但是，也会对一些表的更新操作产生不良的影响。当在表中建立的索引越多，这个不利影响也会越大。故数据库管理员在设置索引的时候，还需要注意，在这两个之间需要一个均衡点。
按照一般的理论来说，当某个表多数用来查询、更新相对来说比较上的话，则要多多采用索引。相反，当某个表记录更新居主导，查询相对来说比较少的话，则不要建立太多的索引，避免对更新的速度差生不利影响。
在实际工作中，若某个表频繁的被视图所调用的话，则最好就好设置比较多的索引了。
