oracle索引

什么情况下应该使用B*树索引？
我并不盲目地信息“经验“（所有规则都有例外） ，所以，对于什么时候该使用（和不该使用）B*树索引，我没有什么经验可以告诉你。为了说明为什么在这方面不能提供经验，下面给出两种做法，这两种做法同等有效：
仅当要通过索引访问表中很少的一部分行（只占一个很小的百分比）时，才使用B*树在列上建立索引。
如果要处理表中的多行，而且可以使用索引而不用表，就可以使用一个B*树索引。
这两个规则看上去彼此存在冲突，不过在实际中，它们并不冲突，只是涵盖了两种完全不同的
情况。根据以上建议，有两种使用索引的方法：
索引用于访问表中的行：通过读索引来访问表中的行。此时你希望访问表中很少的一部分行（只占一个很小的百分比）。
索引用于回答一个查询：索引包含了足够的信息来回答整个查询，我根本不用去访问表。在这种情况下，索引则用作一个“较瘦“版本的表

如果必须完成TABLE ACCESS BY INDEX ROWID，就必须确保只访问表中很少的一部分块（只占很小的百分比），这通常对应为很少的一部分行，或者需要能够尽可能快地获取前面的几行（最终用户正在不耐烦地等着这几行）。如果我们访问的行太多（所占百分比过大，
不在总行数的1%~20%之间） ，那么与全表扫描相比，通过B*树索引来访问这些数据通常要花更长的时间。
对于第二种类型的查询，即答案完全可以在索引中找到，情况就完全不同了。我们会读一个索引块，选出许多“行“来处理，然后再到另一个索引块，如此继续，在此 从不访问表。某些情况下，还可以在索引上执行一个快速全面扫描，从而更快地回答这类查询。快速全面扫描是指，数据库不按特定的顺序读取索引块，而只是开始 读取它们。这里不再是把索引只用作一个索引，此时索引更像是一个表。如果采用快速全面扫描，将不再按索引条目的顺序来得到行


位图索引在读密集的环境中能很好地工作，但是对于写密集的环境则极不适用。原因在于，一个位图索引键条目指向多行。如果一个会话修改了所索引的数据，那么在大多数情况下，这个索引条目指向的所有行都会被锁定。Oracle无 法锁定一个位图索引条目中的单独一
位；而是会锁定这个位图索引条目。倘若其他修改也需要更新同样的这个位图索引条目，就会被“关在门外“。这样将大大影响 并发性，因为每个更新都有可能锁定数百行，不允许并发地更新它们的位图列。在此不是像你所想的那样锁定每一行，而是会锁定很多行。位图存储在块（chunk）中，所以，使用前面的EMP例子就可以看到，索引键ANALYST在索引中出现了多次，每一次都指向数百行。更新一行时，如果修改了JOB列， 则需要独占地访问其中两个索引键条目：对应老值的索引键条目和对应新值的索引键条目。这两个条目指向的数百行就不允许其他会话修改，直到UPDATE提交


无论是更新父表主键，或者删除一个父记录，都会在子表中加一个表锁（在这条语句完成前，不允许对子表做任何修改）。这就会不必要地锁定更多的行，而影响并发性