昨天碰到一个很有意思的问题，一个sql 语句，加上 SoftUseLine like ‘%OQC%‘ 之后，速度就特别慢。去掉该条件之后，速度就快起来了。

　　查看sql 语句的执行情况，发现加上那个查询条件之后，SoftWareDetailInfo表的逻辑读取变成了1300374 次，

　　可是这个查询字段明明已经加上Index_SoftWareDetail索引了，怎么会逻辑读取还这么大呢。查看sql profile 的详细信息，发现sql 语句，没有走那个索引。

　　于是，加上WITH(INDEX(Index_SoftWareDetail)) ，让sql 必须走这个索引试试。Sql查询立马变快了。sql profile 显示，已经走了Index_SoftWareDetail索引。看来是索引创建的有问题，导致查询计划，没有走该索引，而是进行全表扫描。所以导致查询速度变慢。

　　于是把所有索引重新调整下。Ok了。

　　数据库中索引什么时候会失效呢?

　　总结下数据库中索引失效的问题，不过有些没有经过测试。这里仅供自己参考。

　　首先，所谓失效。并不真的就是这个索引被删除了。而是在某些情况下，DBMS不会检索索引列表了。执行速度和没有这个索引时的速度一样。但是再执行另外的一条语句。同样的索引又正常起作用。所以索引的失效是针对某条sql语句，某个查询条件的，而不是针对索引本身的。

　　哪类语句执行时索引不起作用呢。总结如下：

　　1. 索引字段进行判空查询时。也就是对索引字段判断是否为NULL时。语句为is null 或is not null。

　　比如：select * from SoftWareDetailInfo where CreateTime is null 此时就不检索time字段上的索引表了。也就是索引在这条语句执行时失效了。

　　接着再执行

　　select * from SoftWareDetailInfo where CreateTime = ‘2015-04-11 00:00:00‘ 此时就会检索索引表了。索引又起作用了。

　　2. 对索引字段进行like查询时。比如：select * from SoftWareDetailInfo where SoftUseLine like ‘%OQC%‘。不过网上有的例子说like ‘xx%‘索引起作用。我没试过。

　　3. 判断索引列是否不等于某个值时。‘!=’操作符。比如：select * from SoftWareDetailInfo where SoftUseLine != 0

　　4. 对索引列进行运算。这里运算包括+-*/等运算。也包括使用函数。比如：

　　select * from SoftWareDetailInfo where SoftUseLine +0= 0

　　此时索引不起作用。

　　select * from SoftWareDetailInfo where count(SoftUseLine) = 0

　　此时索引也不起作用。

　　也就是说如果不是直接判断索引字段列，而是判断运算或其它函数处理后的索引列索引均不起作用。

　　5. 复合索引中的前导列没有被作为查询条件。比如：Index_SoftWareDetail索引包含（a，b，c） 三列，但是查询条件里面，没有a，b 列，只有c 列，那么 Index_SoftWareDetail索引也不起作用，但是用a或a,b或a,b,c作为条件时都可以使用该索引，即第一个索引字段必须使用，查询是索引才会有效。

记录数据库中索引失效的问题