【转】Mysql索引失效的情况

在工作中经常能遇到索引失效的情况，只要索引失效就导致了SQL查询慢，服务响应慢，用户体验差的情况；所以下面我们就讨论一下MySQL中索引失效的情况

口诀

全职匹配我最爱，最左前缀要遵守；
带头大哥不能死，中间兄弟不能断；
索引列上少计算，范围之后全失效；
LIKE百分写最右，覆盖索引无所谓；
不等空值还有 OR，索引影响要注意；
VAR 引号不可丢，SQL 优化有诀窍。

1.首先创建表

create table staffs(
    -> id int primary key auto_increment,
    -> name varchar(24) not null default '' comment '姓名',
    -> age int not null default 0 comment '年龄',
    -> pos varchar(20) not null default ''comment '职位',
    -> add_time TIMESTAMP not null default CURRENT_TIMESTAMP comment'入职时间'
    -> )charset utf8 comment '员工记录表';

2.添加测试数据

insert into staffs(name,age,pos,add_time)values ('z3',22,'manager',NOW());
insert into staffs(name,age,pos,add_time)values ('July',23,'dev',NOW());
insert into staffs(name,age,pos,add_time)values ('2000',23,'dev',NOW());

3.创建索引

mysql> create index idx_staffs_nap  on staffs(name,age.pos);

4.查看索引

mysql> show index from staffs;

EXPLAIN 查看执行过程时， type 是查询的访问类型。
结果值从最好到最坏依次是（缩略版）：
System > const > eq_ref > ref > range > index > ALL

5.口诀解释

5.1 全职匹配我最爱

最理想的情况就是查询条件刚好和索引完全匹配

5.2 带头大哥不能死

第一条sql中使用了头索引，type为ref，
而第二条sql中第一个索引没有使用，所以type 为最坏类型ALL 并且key为NULL

5.3 中间兄弟不能断

可以看到第二条sql中key为74 是因为索引中断造成的而第一行的sql中包含name,age,pos

5.4 索引列上少计算

不在索引列上做任何操作（计算、函数、（自动or手动）类型转换），会导致索引失效而转向全表扫描
可以看到当使用left（name,4）函数时索引失效

5.5 范围之后全失效

可以看到使用" > "后索引类型由ref ->>range
key_len由140–>78
是因为age>24导致索引失效
mysql在执行sql时底层会使用Optimizer（查询优化器）优化语句使之改成explain select * from staffs where name=‘July’ and pos =‘manager’ and age>24 ;
所以也就是为什么age>24在中间位置，而范围后全失效后，key_len是78 （两个索引）而不是一个索引的原因