MySQL高级：索引优化之防止索引失效

前言：数据库索引优化，但是可能出现索引失效，我们该怎样防止这种情况发生呢》》

文章目录

1. 案例建表：
- 1.1 staffs表
- 1.2 建立索引：
2.案例：索引失效
- 2.1 全面匹配索引的字段最好，第一个字段不能少，也不能，跳着使用字段。
- 2.2 不要在索引的列上做任何操作（计算，函数（自动或者手动）类型转化），会导致索引失效而转向全表扫描
- 2.3 存储引擎不能使用索引中范围条件右边的列：
- 2.4 尽量使用索引覆盖，少用select *：
- 2.5 在使用 != or<> 导致索引失效，全表扫描
- 2.6 is null 或者 is not null 也会导致索引失效
- 2.7 like以通配符%开头会变成全表扫描
- 2.8 varchar类型不写单引号，会索引失效！
- 2.9 少用 or ，他也会导致索引失效！
3 小总结：

1. 案例建表：

1.1 staffs表

 craete table staffs(id int  primary key auto_increment,name varchar(20) not null ,age int not null,pos varchar(20) not null comment '职位',add_time timestamp not null)ENGINE=InnoDB DEFAULT CHARSET=utf8;insert into staffs(name,age,pos,add_time)values('z3',18,'manager',now());insert into staffs(name,age,pos,add_time)values('l4',20,'manager',now());insert into staffs(name,age,pos,add_time)values('w5',23,'manager',now());select * from staffs;

1.2 建立索引：

 alter table staffs add index idx_staffs_nameAgePos(name,age,pos);

2.案例：索引失效

下面为索引失效的一些情况：

2.1 全面匹配索引的字段最好，第一个字段不能少，也不能，跳着使用字段。

但是注意下面的例子：

直接从所建索引的第二个字段开始，则 type 是 ALL，没有用到索引。索引失效了！第一个字段不能少！！！

但是如果只有第一个字段，索引是有效的！！！
!这情况就好比是上楼梯：修好的楼梯是一二三楼，而你使用的时候直接用二三楼，那怎么能上去！所有索引失效了！

这个中间字段没有直接有的第三个字段！
发现第一个字段显然用到了自带，但是第三个却灭有！
也不能，跳着使用字段。

!所以在使用的时候最好使用索引的全部字段，不能么有第一个字段，中间字段也不能断，那样索引就失效了

2.2 不要在索引的列上做任何操作（计算，函数（自动或者手动）类型转化），会导致索引失效而转向全表扫描

上面两个查出来的结果相同，但是第二个用了 left（）函数，看看他们两个的过程分析：

显然，第二种索引使用为 null，索引失效了！

2.3 存储引擎不能使用索引中范围条件右边的列：

当我们所查列中包含范围的情况：

我们可以看出 name，age 用到了索引，后面的没用到索引，type 从 ref --》range 效率还降低了
索引又失效了！

!通俗的说就是使用范围的情况之后，索引就失效了

2.4 尽量使用索引覆盖，少用select *：

当查询字段是索引所包含的列时候，出现了using index ，索引覆盖！这种情况就比前者更好！

2.5 在使用 != or<> 导致索引失效，全表扫描

看下图：

使用!= 或者 <> 索引失效！

2.6 is null 或者 is not null 也会导致索引失效

看结果：

2.7 like以通配符%开头会变成全表扫描

上图三条sql 除了like后面的%位置不同，其他都一样。可以看出以% 开头都是全部扫描！
通配符的位置不同，查结果不同

但是必须使用这情况应该怎样解决！

!使用索引覆盖可以优化这种情况

这样就可了！

2.8 varchar类型不写单引号，会索引失效！

原因是mysql自动产生了类型转化！！！

2.9 少用 or ，他也会导致索引失效！

结果可以查出来，但是过程曲折！

3 小总结：

假设符合索引 inded(a,b,c);
做下面的题！

可看其他案例：三表案例