Oracle Index索引无效的原因与解决方法

索引无效原因

最近遇到一个oracle sql语句的性能问题，修改功能之前的运行时间平均为0.3s，可是添加新功能后，时间达到了4~5s。虽然几张表的数据量都比较大（都在百万级以上），但是也都有正确创建索引，不知道到底慢在了哪里，下面展开调查。

经过几次排除，把问题范围缩小在索引上，首先在确定索引本身没有问题的前提下，考虑索引有没有被使用到，那么新的问题来了，怎么知道指定索引是否被启用。

判断索引是否被执行

1. 分析索引

即将索引至于监控状态下，对索引进行分析。如下对 id_tt_shohou_hist_002 索引进行分析

alter index id_tt_shohou_hist_002 monitoring usage;

2. 查看v$object_usage视图中记录的信息

select * from v$object_usage;

字段依次为：

•index_name --索引名

•table_name --表名

•monitoring --是否被监控

• used --是否被启用

•start_monitoring --监控开始时间

•end_monitoring --监控结束时间

如上图，虽然索引已经被引用，但是速度依旧很慢，莫非是虽然启用了索引，但是又被其他的一些原因拖慢了速度，继续调查。

调查途中，收集到一些oracle 数据库不走索引的原因分享给大家

不走索引的原因

1. 在索引列上使用函数时不会使用索引

例如常见的， to_char 、 to_date 、 to_number 、 trunc ...等等。

此时的解决办法可以使用 函数索引 ，顾名思义就是把使用函数后的字段整体当成索引中的字段。

如下图中的 to_char(shohou_date, 'yyyymmdd') 就是一个函数索引，因为日期字段中含有时分秒，进行日期比较的时候，必须转化成固定的格式。

create index id_tt_shohou_hist_003
on tt_shohou_hist
(del_flg,to_char(shohou_date, 'yyyymmdd'), shohou_id)
tablespace salespa_index

2. 索引的列进行隐式的类型转换

select * from table where index_colum = 5

上面语句中的 index_colum 字段类型为 varchar2 ，这时就会发生隐式类型转换，类似于

select * from table where to_number(index_colum) = 5

3. where 子句中使用不等于操作

不等于操作包括： <> , != , not colum >= ? , not colum <= ?

替代方式可以使用or， colum <> 0 =====> colum > 0 or colum < 0;

4. 使用 is null 和 is not null

替代方式：函数索引

通过 nvl(b,c) 将为空的字段转为不为空的c值，再在函数nvl(b,c)上建立函数索引

转换前

select * from a where b = null

转换后

select * from a where nvl(b,c) = c

5. 组合索引

组合索引：由多个列构成的索引。如

create index index_emp on emp (col1,col2,col3,...)

index_emp 则为复合索引， col1 为引导列。进行查询时，可以使用 where col1 = ? ，也可以使用 where col1 = ? and col2 = ? ，这样的限制条件都会使用索引，但是 where col2 = ? ，不会使用索引，所以限制条件中包含引导列时，该限制条件才会使用组合索引。

经过一番调查，我使用的sql语句检索条件中对时间列进行 to_char(ttsh.shohou_date, 'yyyymmdd') 格式化日期，去除掉时分秒。再建立函数索引后仍然没有起到优化加速的效果，仔细观察发现在使用to_char格式化时间之后，又进行to_date转为时间格式和其他子查询的字段进行比较。然后很快想到，建立一个 to_date(to_char(ttsh.shohou_date, 'yyyymmdd'), 'yyyymmdd') 这样的函数索引，结果缺失提高了不少的运行速度，从4~5s缩短到了0.5s左右。

但是这只是在pl/sql软件中运行sql提高了速度，实际项目运行仍然是4~5s，使用语句查看索引的使用状况时，发现并没有使用索引，但是在pl/sql软件中确实调用了索引，这至今都是未解之谜，如果有大神知道原因希望能帮我解答一下这个疑问。

既然不能自动调用，只能强制让sql走指定索引了，强制的方法如下

在 select 语句后加入 /*+index(ttsh id_tt_shohou_hist_002)*/ ，其中 ttsh 是表的别名（当表有别名的时候，必须在索引前加入表的别名）

select /*+index(ttsh id_tt_shohou_hist_002)*/ 
to_date(to_char(ttsh.shohou_date, 'yyyymmdd'), 'yyyymmdd') as shohou_date 
from tt_shohou_hist ttsh
where ...

至此，sql的效率问题已经解决了，但是这不是最好的解决方案。

首先，目前的索引中已经存在包含 to_char(ttsh.shohou_date, 'yyyymmdd') 的函数索引，又再创建一个 to_date(to_char(ttsh.shohou_date, 'yyyymmdd'), 'yyyymmdd') ，看着就很难受

其次，强制使用索引的方法需要在sql中指定索引名，假如数据库中的索引名发生变更，还需去更改sql。

最好的方法是把索引字段的to_date去掉，统一使用to_char的索引。

and cal.calender = to_date(to_char(ttsh.shohou_date, 'yyyymmdd'), 'yyyymmdd')

上面的部分语句因为 calender 字段是date类型，所以比较时使用了to_date，其实只要把 calender 转化成char类型就行了，虽然看起来要改动的地方很多，其实解决了更大的问题。

总结

以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对的支持。