mysql 索引失效总结10种场景

Posted 2023-03-30 怀梦

前言

在实际工作中，有没有遇到过下面的这两种情况：

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

准备工作

创建表和造数据

DROP TABLE IF EXISTS `user`;
CREATE TABLE `user` (
  `id` int NOT NULL AUTO_INCREMENT,
  `code` varchar(20) COLLATE utf8mb4_bin DEFAULT NULL,
  `age` int DEFAULT '0',
  `name` varchar(30) COLLATE utf8mb4_bin DEFAULT NULL,
  `height` int DEFAULT '0',
  `address` varchar(30) COLLATE utf8mb4_bin DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_height` (`height`),
  KEY `idx_code_age_name` (`code`,`age`,`name`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin

INSERT INTO `user` (`id`, `code`, `age`, `name`, `height`, `address`) VALUES (1, '101', 21, '周星驰', 175, '香港');
INSERT INTO `user` (`id`, `code`, `age`, `name`, `height`, `address`) VALUES (2, '102', 18, '周杰伦', 173, '台湾');
INSERT INTO `user` (`id`, `code`, `age`, `name`, `height`, `address`) VALUES (3, '103', 23, '荷逸', 174, '济南');

此外，还创建了三个索引：

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

失效场景

1、不满足最左匹配原则

之前已经给code、age和name这3个字段建好联合索引：idx_code_age_name

索引字段的顺序是：

• code
• age
• name

如果在使用联合索引时，没注意最左前缀原则，很有可能导致索引失效

哪些情况索引有效？

explain select * from user where code='101';  有

explain select * from user where code='101' and age=21; 有

explain select * from user where code='101' and age=21 and name='周星驰'; 有

上面三种情况，sql都能正常走索引

还有一种比较特殊的场景：

explain select * from user where code = '101' and name='周星驰';

查询条件原本的顺序是：code、age、name，但这里只有code和name中间断层了，掉了age字段，这种情况也能走code字段上的索引。

规律发现：这4条sql中都有code字段，它是索引字段中的第一个字段，也就是最左边的字段。只要有这个字段在，该sql已经就能走索引。

这就是我们所说的最左匹配原则

哪些情况索引失效？

下索引会失效情况

explain select * from user where age=21;  失效

explain select * from user where name='周星驰'; 失效

explain select * from user where age=21 and name='周星驰';  失效

从图中看出这3种情况下索引失效了

说明以上3种情况不满足最左匹配原则，说白了是因为查询条件中，没有包含给定字段最左边的索引字段，即字段code。

2、使用了select *

在《阿里巴巴开发手册》中明确说过，查询sql中禁止使用select * 。

explain select * from user where name='周星驰';

在该sql中用了select *，从执行结果看，走了全表扫描，没有用到任何索引，查询效率是非常低的。

如果查询的时候，只查我们真正需要的列，而不查所有列，结果会怎么样？

explain select code,name from user where name='周星驰';

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

其实这里用到了：覆盖索引。

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

3、索引列上有计算

回顾一下，根据id查询数据的sql语句：

explain select * from user where id = 1;

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

但如果id列上面有计算，比如：

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

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

4、索引列用了函数

在某条sql语句的查询条件中，需要使用函数，比如：截取某个字段的长度。

假如现在有个需求：想查出所有身高是17开头的人，如果sql语句写成这样

explain select * from user  where height = 17;

该sql语句确实用到了普通索引：

但该sql语句肯定是有问题的，因为它只能查出身高正好等于17的，但对于174这种情况，它没办法查出来。

为了满足上面的要求，我们需要把sql语句稍稍改造了一下：

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

这时需要用到SUBSTR函数，用它截取了height字段的前面两位字符，从第一个字符开始。

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

5、字段类型不同

在sql语句中因为字段类型不同，而导致索引失效的问题，很容易遇到，在我们日常工作中最容易忽略的问题。

在t_user表中的code字段，它是varchar字符类型的

在sql语句中查询数据时，查询条件我们可以写成这样：

explain select * from user where code = "101";

从上图中看到，该code字段走了索引。

但如果在写sql时，不小心把引号弄掉了，把sql语句变成了：

explain select * from user where code = 101;

惊奇的发现，该sql语句竟然变成了全表扫描。因为少写了引号，这种小小的失误，竟然让code字段上的索引失效了。

这时你心里可能有一万个为什么，其中有一个肯定是：为什么索引会失效呢？

答：因为code字段的类型是varchar，而传参的类型是int，两种类型不同。

此外，还有一个有趣的现象，如果int类型的height字段，在查询时加了引号条件，却还可以走索引：

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

从图中看出该sql语句确实走了索引。int类型的参数，不管在查询时加没加引号，都能走索引。

这是变魔术吗？这不科学呀。

答：mysql发现如果是int类型字段作为查询条件时，它会自动将该字段的传参进行隐式转换，把字符串转换成int类型。

mysql会把上面列子中的字符串175，转换成数字175，所以仍然能走索引。

接下来，看一个更有趣的sql语句：

select 1 + '1';

它的执行结果是2，还是11呢？

直接公布答案执行结果是2。

mysql自动把字符串1，转换成了int类型的1，然后变成了：1+1=2。

但如果你确实想拼接字符串该怎么办？

答：可以使用concat关键字。

具体拼接sql如下：

select concat(1,'1');

6、like左边包含%

假如现在有个需求：想查出所有code是10开头的用户。

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

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

而如果把需求改了：想出现出所有code是1结尾的用户。

查询sql语句改为：

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

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

此外，如果出现以下sql：

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

该sql语句的索引也会失效。

7、列对比

假如我们现在有这样一个需求：过滤出表中某两列值相同的记录。比如user表中id字段和height字段，查询出这两个字段中值相同的记录。

explain select * from user where id = height

为什么会出现这种结果？

id字段本身是有主键索引的，同时height字段也建了普通索引的，并且两个字段都是int类型，类型是一样的。

但如果把两个单独建了索引的列，用来做列对比时索引会失效。

8、使用or关键字

查一下id = 1或者height = 175的用户

explain select * from user where id = 1 or height = '175';

mysql 8.0：

mysql 5.7

所以在8.0的情况下，是可以引用到索引的，但5.7的情况下没有。

除了前面的查询条件之后，还想加一个address=‘成都’。

explain select * from user where id = 1 or height = '175' or address = '成都';

结果悲剧了，之前的索引都失效了。

因为你最后加的address字段没有加索引，从而导致其他字段的索引都失效了。

注意：如果使用了or关键字，那么它前面和后面的字段都要加索引，不然所有的索引都会失效，这是一个大坑

9、not in和not exists

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

• in
• exists
• not in
• not exists
• between and

in关键字

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

explain select * from user where height in (173);

从图中可以看出，sql语句中用in关键字是走了索引的。

但是超出一定范围就不走索引了，一般是30%

explain select * from user where height in (173, 174, 175);

exists关键字

有时候使用in关键字时性能不好，这时就能用exists关键字优化sql了，该关键字能达到in关键字相同的效果：

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

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

mysql 索引失效总结

参考技术A

首先我们还是先把表结构说下：用户表tb_user结构如下：

1、 不要在索引列上进行运算操作， 索引将失效。

手机号phone字段有唯一索引，当根据phone字段进行函数运算操作之后，索引失效:

2、 字符串类型字段使用时，不加引号，索引将失效。

如果字符串不加单引号，对于查询结果，没什么影响，但是数 据库存在隐式类型转换，索引将失效。

3、 如果仅仅是尾部模糊匹配，索引不会失效。如果是头部模糊匹配，索引失效。

接下来，我们来看一下这三条SQL语句的执行效果，查看一下其执行计划：

由于下面查询语句中，都是根据profession（专业）字段查询，profession字段是一个普通的索引， 我们主要看一下，模糊查询时，%加在关键字之前，和加在关键字之后的影响。

经过上述的测试，我们发现，在like模糊查询中，在关键字后面加%，索引可以生效。而如果在关键字 前面加了%，索引将会失效。

4、 用or分割开的条件， 如果or前的条件中的列有索引，而后面的列中没有索引，那么涉及的索引都不会 被用到。

由于age没有索引，所以即使id有索引，索引也会失效。所以需要针对于age也要建立索引。

5、 数据分布影响：如果MySQL评估使用索引比全表更慢，则不使用索引。