Mysql索引失效场景集合

我们经常会遇到两种情况:

明明在某个字段上加了索引，但实际上并没有生效。
索引有时候生效了，有时候没有生效。

索引失效的场景汇总如下：

使用select *
索引列上有计算操作
索引列上有函数操作
字段类型不同
like左边包含%
进行索引的列对比
not in和not exist

准备数据

CREATE TABLE example
(  id      int NOT NULL AUTO_INCREMENT,  code    varchar(20) DEFAULT NULL,  age     int         DEFAULT 0,  name    varchar(30) DEFAULT NULL,  height  int         DEFAULT 0,  PRIMARY KEY (id),  KEY idx_code_age_name (code, age, name),  KEY idx_height (height)
); INSERT INTO example (id, code, age, name, height, address)
VALUES (1, '10', 21, '张三', 175, '北京');
INSERT INTO example(id, code, age, name, height, address)
VALUES (2, '11', 18, '李四', 173, '上海');
INSERT INTO example (id, code, age, name, height, address)
VALUES (3, '12', 23, '王武', 174, '广州');
INSERT INTO example (id, code, age, name, height, address)
VALUES (4, '13', 22, '马六', 154, '重庆');

创建了三个索引

id：数据库的主键
idx_code_age_name：由code、age和name三个字段组成的联合索引
idx_height：普通索引

查看执行计划，可以使用explain关键字，例如：

explain select * from example where id=1;

执行结果：

从图中可以看出，由于id字段是主键，该SQL语句用到了主键索引

使用`select *`

案例SQL

explain
select * from example where name='苏三';

执行结果

说明

在该SQL中用了select *，从执行结果看，走了全表扫描，没有用到任何索引，查询效率是非常低的。
如果查询的时候，只查我们真正需要的列，而不查所有列，查询效率会有提升

explain
select code,name from example
where name='苏三';

执行结果

从执行结果不难看出，该SQL语句这次走了全索引扫描，比全表扫描效率更高

如果select语句中的查询列，都是索引列，那么这些列被称为覆盖索引。这种情况下，查询的相关字段都能走索引，索引查询效率相对来说更高一些，而使用select *查询所有列的数据，大概率会查询非索引列的数据，非索引列不会走索引，查询效率非常低

索引列上有计算操作

顾名思义就是在查询条件上加上计算比对操作，如下面的例子,id列上有计算：

explain select * from example where id+1=2;

执行结果：

从上图中的执行结果，能够非常清楚的看出，该id字段的主键索引，在有计算的情况下失效了

索引列上有函数操作

有时候我们在某条SQL语句的查询条件中，需要使用函数，比如：截取某个字段的长度
例如想要查询身高带有17开头的用户

explain select * from example where SUBSTR(height,1,2)=17;

执行结果

在使用该函数之后，该SQL语句走了全表扫描，索引失效

此处讨论的是函数操作对索引的影响，因此like关键字不再此讨论范围内

字段类型不同

在SQL语句中因为字段类型不同，而导致索引失效的问题，很容易遇到，可能是我们日常工作中最容易忽略的问题
在sql语句中查询数据时，查询条件我们可以写成这样：

explain
select * from example where code='101';

执行结果：

从上图中看到，该code字段走了索引，但如果在写SQL时，不小心把引号弄掉了，把SQL语句变成了

explain
select * from example where code=101;

执行结果：

你会惊奇的发现，该SQL语句竟然变成了全表扫描。因为少写了引号，这种小小的失误，竟然让code字段上的索引失效了
因为code字段的类型是varchar，而传参的类型是int，两种类型不同，导致了索引失效
但是有时大家也会发现下面一种场景：

explain
select * from example where height='175';

执行结果：

从图中看出该SQL语句确实走了索引。int类型的参数，不管在查询时加没加引号，都能走索引，这是因为MySQL发现如果是int类型字段作为查询条件时，它会自动将该字段的传参进行隐式转换，把字符串转换成int类型。

因此在写SQL时，需要确保查询条件的类型与查询字段类型一致，以免发生不必要的转换，消耗数据库的性能。

like左边包含

模糊查询，在我们日常的工作中，使用频率还是比较高的
目前like查询主要有三种情况:

like ‘a%’
like ‘%a’
like ‘%a%’

例如：想查出所有code是10开头的用户

explain
select * from example where code like '10%';

执行结果：

图中看出这种%在10右边时走了索引

例如：如果想查出所有code是1结尾的用户

explain
select * from example where code like '%1';

执行结果：

从图中看出这种%在1左边时，code字段上索引失效了，该SQL变成了全表扫描

此外，如果出现以下SQL

explain
select * from example where code like '%1%';

执行结果：

该SQL语句的索引也会失效
因为索引就像字典中的目录，一般目录是按字母或者拼音从小到大，从左到右排序，是有顺序的。我们在查目录时，通常会先从左边第一个字母进行匹对，如果相同，再匹对左边第二个字母，如果再相同匹对其他的字母，以此类推。通过这种方式我们能快速锁定一个具体的目录，或者缩小目录的范围

进行索引的列对比

过滤出表中某两列值相同的记录。比如example表中id字段和height字段，查询出这两个字段中值相同的记录

explain
select * from example where id=height;

执行结果：

从图中可以看出，索引失效了。
id字段本身是有主键索引的，同时height字段也建了普通索引的，并且两个字段都是int类型，类型是一样的。
但如果把两个单独建了索引的列，用来做列对比时索引会失效

`not in`和`not exist`

在我们日常工作中用得也比较多的，还有范围查询，常见的有：

in
exists
not in
not exists
between and

not in

假如我们想查出height不在某些范围之内的用户，这时SQL语句可以这样写：

explain
select * from example where height not in (173,174);

执行结果：

从上图可以看出，索引在此处失效了

not exists

SQL在使用not exists也会出现索引失效的情况，具体SQL如下：

explain
select * from example  t1
where  not exists (select 1 from example t2 where t2.height=173 and t1.id=t2.id);

执行结果：

从图中看出SQL语句中使用not exists关键后，t1表走了全表扫描，并没有走索引

如有疑问请提issue: https://gitee.com/huangmike/itshare