共计 2543 个字符，预计需要花费 7 分钟才能阅读完成。
索引无效原因
最近遇到一个 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_INDEX2. 索引的列进行隐式的类型转换
SELECT * FROM TABLE WHERE INDEX_COLUM = 5上面语句中的 INDEX_COLUM 字段类型为VARCHAR2，这时就会发生隐式类型转换，类似于
SELECT * FROM TABLE WHERE TO_NUMBER(INDEX_COLUM) = 53. 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) = C5. 组合索引
组合索引：由多个列构成的索引。如
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 类型就行了，虽然看起来要改动的地方很多，其实解决了更大的问题。
更多 Oracle 相关信息见Oracle 专题页面 https://www.linuxidc.com/topicnews.aspx?tid=12
：
