索引失效和注意事项
Sql

索引失效的情况

如果是同样的sql如果在之前能够使用到索引,那么现在使用不到索引,以下几种主要情况:

  1. 随着表的增长,where条件出来的数据太多,大于15%,使得索引失效(会导致CBO计算走索引花费大于走全表)

  2. 统计信息失效 需要重新搜集统计信息

  3. 索引本身失效 需要重建索引

具体情况:

1.单独引用复合索引里非第一位置的索引列

假如有INDEX(a,b,c), 
当条件为a或a,b或a,b,c时都可以使用索引, 
但是当条件为b,c时将不会使用索引。

复合索引遵守“最左前缀”原则,即在查询条件中使用了复合索引的第一个字段,索引才会被使用。因此,在复合索引中索引列的顺序至关重要。如果不是按照索引的最左列开始查找,则无法使用索引。

2.对索引列运算,运算包括(+、-、*、/、!、<>、%、like’%_’(%放在前面)、or、in、exist等),导致索引失效。

错误的例子:select * from test where id-1=9; 
正确的例子:select * from test where id=10; 
注意!! 
mysql sql 中如果使用了 not in , not exists , (<> 不等于 !=) 这些不走 
< 小于 > 大于 <= >= 这个根据实际查询数据来判断,如果全盘扫描速度比索引速度要快则不走索引 。

3.对索引应用内部函数,这种情况下应该建立基于函数的索引。

select * from template t where ROUND(t.logicdb_id) = 1 
此时应该建ROUND(t.logicdb_id)为索引。

4、类型错误,如字段类型为varchar,where条件用number。

例:template_id字段是varchar类型。

错误写法:select * from template t where t.template_id = 1

正确写法:select * from template t where t.template_id = ‘1’

5.如果MySQL预计使用全表扫描要比使用索引快,则不使用索引 
6.like的模糊查询以%开头,索引失效 
7.索引列没有限制 not null,索引不存储空值,如果不限制索引列是not null,oracle会认为索引列有可能存在空值,所以不会按照索引计算


索引注意事项

https://blog.csdn.net/qq_16239775/article/details/79665972

1.索引不会包含有NULL值的列

只要列中包含有NULL值都将不会被包含在索引中,复合索引中只要有一列含有NULL值,那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为NULL。应该用0、一个特殊的值或者一个空串代替空值。

2.复合索引

比如有一条语句是这样的:select * from users wherearea=’beijing’ and age=22;如果我们是在area和age上分别创建单个索引的话,由于mysql查询每次只能使用一个索引,所以虽然这样已经相对不做索引时全表扫描提高了很多效率,但是如果在area、age两列上创建复合索引的话将带来更高的效率。如果我们创建了(area,age,salary)的复合索引,那么其实相当于创建了(area,age,salary)、(area,age)、(area)三个索引,这被称为最佳左前缀特性。因此我们在创建复合索引时应该将最常用作限制条件的列放在最左边,依次递减

3.使用短索引

对串列进行索引,如果可能应该指定一个前缀长度。例如,如果有一个CHAR(255)的列,如果在前10 个或20 个字符内,多数值是惟一的,那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。

4.排序的索引问题

mysql查询只使用一个索引,因此如果where子句中已经使用了索引的话,那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作尽量不要包含多个列的排序,如果需要最好给这些列创建复合索引

5.like语句操作

一般情况下不鼓励使用like操作,如果非使用不可,如何使用也是一个问题。like“%aaa%” 不会使用索引而like“aaa%”可以使用索引。

6.不要在列上进行运算

select* from users where YEAR(adddate)

7.不使用NOT IN操作

NOT IN操作都不会使用索引将进行全表扫描。NOT IN可以NOT EXISTS代替

Responses