总结一下索引失效的原因：
单独引用复合索引里非第一位置的索引列。
表没分析
like ‘’%_''百分号在前（百分号在后面是不会的）
单独的>或<; <>
字符型字段为数字时在where条件里不添加引号
对索引列进行运算，需要建立函数索引
not in ， not exist
当变量采用的是times变量，而表的字段采用的是date变量时，或相反情况
索引失效
基于cost成本分析（oracle因为走全表成本会更小），查询小表，或者相反情况
drop重建
B-tree索引 is null不会走，is not null会走；位图索引 is null，is not null 都会走
联合索引 is not null 只要在建立的索引列（不分先后）都会走的；is null时 必须要和建立索引第一列一起使用，当建立索引第一位置条件是is null时，其他建立索引的列可以是is null （但必须在所有列满足is null的时候），或者 = 一个值；当建立索引的第一位置是=一个值时，其他索引列可以是任何情况（包括is null=一个值），以上两种情况索引都会走。其他情况不会走
索引失效的解决方法：
选用适合的Oracle优化器 Oracle的优化器共有三种： a.RULE（基于规则）b.COST(基于成本) c.CHOOSE(选择性) 设置缺省的优化器，可以通过对init.ora文件中的OPTIMIZER_MODE参数的各种声明，如RULE,COST,CHOOSE,ALL_ROWS,FIRST_ROWS.你当然也在SQL句级或是会话（session）级对其进行覆盖。 为了使用基于成本的优化器（CBO,Cost-Based Optimizer）,ni必须经常运行analyze命令，以增加数据库中的对象统计信息（object statistics）的准确性。 如果数据库的优化器模式设置为选择性（CHOOSE),那么实际的优化器模式将和是否运行过analyze命令有关。如果table已经被analyze过，优化器模式将自动成为CBO，反之，数据库将采用rule形式的优化器。
（分析table
analyze table PROD_PARTS compute statistics；
analyze table prod_parts compute statistics for all indexed columns;)
【索引失效之后，发现是数据统计问题，具体的解决办法是执行以上语句】
在缺省情况下，Oracle采用choose优化器，为避免那些不必要的全表扫描（full tables scan）,尽量避免使用chosse优化器，而直接采用基于规则或者基于成本的优化器
2.重建索引
alter index 索引名 rebuild [online];
3.强制索引
给该语句加上hint后，强制其使用‘record_entityid’ 这个索引
sql语句变成这样
引用
select /*+ index(record,record_entityid) */ *
from RECORD
where entityId='24' and entityType='blog';
/*+ index(record,record_entityid) */ 中，index表示强制使用index，record是表名，record_entityid是索引名。其执行计划跟测试数据库上一致，都是使用用 'RECORD_ENTITYID' 这个索引，逻辑读写同样为4。
后来经过测试，在不加hint的情况下，对该表和两个索引执行analyze后，同样也能使用‘RECORD_ENTITYID’ 这个索引。但是因为该表更新颇为频繁，不知道要多久就要在analyze一次。
但是 如果同样的sql如果在之前能够使用到索引，那么现在是用不到索引，以下几种主要情况：索引失效的原因主要有如下：
1.随着表的增长，where条件出来的数据太多，大于15%，使得索引失效（会导致CBO计算走索引花费大于走全表）
2.统计信息失效 需要重新搜集统计信息
3.索引本身失效 需要重建索引
select INDEX_NAME,TABLE_NAME
from user_indexes
where STATUS = 'VALID';
