目录

• 1 MySQL索引
  • 1.1 问题引入
  • 1.2 准备工作
    • 1.2.1 创建user表
    • 1.2.3 查看数据库版本
    • 1.2.4 查看执行计划
  • 1.3 联合索引
    • 1.3.1 联合索引中索引有效
    • 1.3.2 联合索引中索引失效
  • 1.4 select *
    在《阿里巴巴开发手册》中明确说过，查询sql中禁止使用select *
    那么，你知道为什么吗？
  • 1.5 索引列上有计算
  • 1.6 索引列用了函数
  • 1.7 字段类型不同
  • 1.8 like左边包含%
  • 1.9 列对比
  • 1.10 使用or关键字
  • 1.11 not in和not exists
    • 1.11.1 in关键字
    • 1.11.2 exists关键字
    • 1.11.3 not in关键字
    • 1.11.4 not exists关键字
  • 1.12 order by的坑
    • 1.12.1 哪些情况走索引
    • 1.12.2 哪些情况不走索引

1 MySQL索引

1.1 问题引入

今天我来聊聊索引的相关问题，因为索引是大家都比较关心的公共话题，确实有很多坑。

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

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

1.2 准备工作

1.2.1 创建user表

创建一张user表，表中包含：id、code、age、name和height字段

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_code_age_name` (`code`,`age`,`name`),
  KEY `idx_height` (`height`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin

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

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

• idx_height：普通索引

  1.2.2 插入数据

  为了方便给大家做演示，我特意向user表中插入了3条数据

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,'成都');

1.2.3 查看数据库版本

为了防止以后出现不必要的误会，在这里有必要查一下当前数据库的版本。

select version();
查出当前的mysql版本号为：8.0.21

1.2.4 查看执行计划

在mysql中，如果你想查看某条sql语句是否使用了索引，或者已建好的索引是否失效，可以通过explain关键字，查看该sql语句的执行计划，来判断索引使用情况。

例如：

explain select * from user where id=1;

执行结果：图片从图中可以看出，由于id字段是主键，该sql语句用到了主键索引

1.3 联合索引

之前我已经给code、age和name这3个字段建好联合索引：idx_code_age_name。
该索引字段的顺序是：

• code
• age
• name

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

1.3.1 联合索引中索引有效

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已经就能走索引。
这就是我们所说的 最左匹配原则

1.3.2 联合索引中索引失效

前面我已经介绍过，建立了联合索引后，在查询条件中有哪些情况索引是有效的。
接下来，我们重点看看哪些情况下索引会失效

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

1.4 select *
在《阿里巴巴开发手册》中明确说过，查询sql中禁止使用select *
那么，你知道为什么吗？

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

执行结果：

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

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

执行结果：

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

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

1.5 索引列上有计算

介绍本章节内容前，先跟大家一起回顾一下，根据id查询数据的sql语句：

explain select * from user where id=1;

执行结果：

从图中可以看出，由于id字段是主键，该sql语句用到了主键索引。
但如果id列上面有计算，比如：

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

执行结果：

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

1.6 索引列用了函数

有时候我们在某条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语句竟然走了全表扫描，索引失效了。

1.7 字段类型不同

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

注意观察一下user表中的code字段，它是varchar字符类型的。
在sql语句中查询数据时，查询条件我们可以写成这样：

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

执行结果：

从上图中看到，该code字段走了索引。
温馨提醒一下，查询字符字段时，用双引号“和单引号'都可以。
MySQL中单双引号分析
但如果你在写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。
mysql自动把字符串1，转换成了int类型的1，然后变成了：1+1=2

但如果你确实想拼接字符串该怎么办？可以使用concat关键字。
具体拼接sql如下：

select concat(1,'1');

接下来，关键问题来了：为什么字符串类型的字段，传入了int类型的参数时索引会失效呢？
根据mysql官网上解释，字符串'1'、' 1 '、'1a'都能转换成int类型的1，也就是说可能会出现多个字符串，对应一个int类型参数的情况。那么，mysql怎么知道该把int类型的1转换成哪种字符串，用哪个索引快速查值?
感兴趣的小伙伴可以再看看官方文档：https://dev.mysql.com/doc/refman/8.0/en/type-conversion.html

1.8 like左边包含%

模糊查询，在我们日常的工作中，使用频率还是比较高的。
比如现在有个需求：想查询姓李的同学有哪些?
使用like语句可以很快的实现：

select * from user where name like '李%';

但如果like用的不好，就可能会出现性能问题，因为有时候它的索引会失效。
目前like查询主要有三种情况：

like '%a'
like 'a%'
like '%a%'

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

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语句的索引也会失效。
下面用一句话总结一下规律：当like语句中的%，出现在查询条件的左边时，索引会失效。

为什么会出现这种现象呢？
其实很好理解，索引就像字典中的目录。一般目录是按字母或者拼音从小到大，从左到右排序，是有顺序的。
我们在查目录时，通常会先从左边第一个字母进行匹对，如果相同，再匹对左边第二个字母，如果再相同匹对其他的字母，以此类推。通过这种方式我们能快速锁定一个具体的目录，或者缩小目录的范围。

1.9 列对比

上面的内容都是常规需求，接下来，来点不一样的。
假如我们现在有这样一个需求：过滤出表中某两列值相同的记录。比如user表中id字段和height字段，查询出这两个字段中值相同的记录。
这个需求很简单，sql可以这样写：

explain select * from user  where id=height

执行结果：

为什么会出现索引失效这种结果
id字段本身是有主键索引的，同时height字段也建了普通索引的，并且两个字段都是int类型，类型是一样的。
但如果把两个单独建了索引的列，用来做列对比时索引会失效

1.10 使用or关键字

我们平时在写查询sql时，使用or关键字的场景非常多，但如果你稍不注意，就可能让已有的索引失效。
某天你遇到这样一个需求：想查一下id=1或者height=175的用户。

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

执行结果：

没错，这次确实走了索引，因为刚好id和height字段都建了索引。
假如需求改了：除了前面的查询条件之后，还想加一个address='成都'。

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

执行结果：

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

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

1.11 not in和not exists

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

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

今天重点聊聊前面四种。

1.11.1 in关键字

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

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

执行结果：

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

1.11.2 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)

执行结果：

从图中可以看出，用exists关键字同样走了索引。

1.11.3 not in关键字

上面演示的两个例子是正向的范围，即在某些范围之内。
那么反向的范围，即不在某些范围之内，能走索引不？

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

执行结果：

索引失效了。
看如果现在需求改了：想查一下id不等于1、2、3的用户有哪些，这时sql语句可以改成这样：

explain select * from user where id  not in (173,174,175,176);

执行结果：

可能会惊奇的发现，主键字段中使用not in关键字查询数据范围，任然可以走索引。而普通索引字段使用了not in关键字查询数据范围，索引会失效。

1.11.4 not exists关键字

除此之外，如果sql语句中使用not exists时，索引也会失效。具体sql语句如下：

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

执行结果：

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

1.12 order by的坑

在sql语句中，对查询结果进行排序是非常常见的需求，一般情况下我们用关键字：order by就能搞定。
但order by挺难用的，它跟where或者limit关键字有很多千丝万缕的联系，一不小心就会出问题。

1.12.1 哪些情况走索引

一起看看order by的哪些情况可以走索引。
我之前说过，在code、age和name这3个字段上，已经建了联合索引：idx_code_age_name

1.12.1.1 配合where一起使用

order by还能配合where一起遵循最左匹配原则。

explain select * from user where code='101' order by age;

执行结果：

code是联合索引的第一个字段，在where中使用了，而age是联合索引的第二个字段，在order by中接着使用。
假如中间断层了，sql语句变成这样，执行结果会是什么呢？

explain select * from user where code='101' order by name;

执行结果：

虽说name是联合索引的第三个字段，但根据最左匹配原则，该sql语句依然能走索引，因为最左边的第一个字段code，在where中使用了。只不过order by的时候，排序效率比较低，需要走一次filesort排序罢了。

1.12.1.2 两者都有

如果某个联合索引字段，在where和order by中都有，结果会怎么样？

explain select * from user where code='101' order by code, name;

执行结果：

code字段在where和order by中都有，对于这种情况，从图中的结果看出，还是能走了索引的。

1.12.2 哪些情况不走索引

前面介绍的都是正面的用法，是为了让大家更容易接受下面反面的用法。
好了，接下来，重点聊聊order by的哪些情况下不走索引？

1.12.2.1 满足最左匹配原则

。

1.12.2.1 没加where

如果order by语句中没有加where关键字，该sql语句将不会走索引。

explain select * from user order by code, name;

执行结果：

从图中看出索引真的失效了。

1.12.2.2 只用limit

只是用limit也不走索引
order by后面的条件，也要遵循联合索引的最左匹配原则。具体有以下sql：

explain select * from user order by code limit 100;

explain select * from user order by code,age limit 100;

explain select * from user order by code,age,name limit 100;

执行结果：

从图中看出这3条sql都不能正常走索引