MySQL数据库——索引（5）-索引使用（上），验证索引效率、最左前缀法则、范围查询、索引失效情况、SQL提示

news2025/1/20 0:57:37

索引使用

验证索引效率

最左前缀法则

范围查询

索引失效情况

索引列运算

字符串不加引号

模糊查询

or连接条件

数据分布影响

SQL提示

use index

ignore index

force index

索引使用（上）

验证索引效率

在讲解索引的使用原则之前，先验证一下索引，看看是否能够通过索引来提升数据查询性能。

在演示的时候，我们还是使用之前的一张表 tb_sku , 在这张表中准备了1000w的记录。

这张表中id为主键，有主键索引，而其他字段是没有建立索引的。我们先来查询其中的一条记录，看看里面的字段情况，执行如下SQL：

select * from tb_sku where id = 1\G;
-- \G使行列互换，展示得更加清晰

查询结果：

可以看到即使有1000w的数据,根据id进行数据查询,性能依然很快，因为主键id是有索引的。

那么接下来，我们再来根据 sn 字段进行查询，执行如下SQL（sn字段没有建立索引）：

SELECT * FROM tb_sku WHERE sn = '100000003145001';

查询结果：

我们可以看到根据sn字段进行查询，查询返回了一条数据，结果耗时 20.78sec，就是因为sn没有索引，而造成查询效率很低。
那么我们可以针对于sn字段，建立一个索引，建立了索引之后，我们再次根据sn进行查询，再来看一下查询耗时情况。

创建索引：

create index idx_sku_sn on tb_sku(sn);

创建这个索引的过程可能会比较久，因为表中的数据比较多，要建立一颗B+Tree 树是需要耗时较长的。

创建完这个索引之后，我们再次执行相同的SQL语句，查看其耗时情况。

SELECT * FROM tb_sku WHERE sn = '100000003145001'\G;

我们明显会看到，sn字段建立了索引之后，查询性能大大提升。建立索引前后，查询耗时都不是一个数量级的。

最左前缀法则

如果索引了多列（联合索引），要遵守最左前缀法则。

最左前缀法则指的是查询从索引的最左列开始，并且不跳过索引中的列。如果跳跃某一列，索引将会部分失效(后面的字段索引失效)。

例如当前在 tb_user 表中，有一个联合索引，这个联合索引涉及到三个字段，顺序分别为：profession，age，status。
对于最左前缀法则指的是，查询时，最左边的列，也就是profession必须存在，否则索引全部失效。而且中间不能跳过某一列，否则该列后面的字段索引将失效。

比如：

查询时，若profession存在，age不存在，status存在，那此时只有profession这个索引会生效；

若profession不存在，age存在，status存在，那此时将不会使用到该索引；

注意：最左前缀法则与查询条件的书写顺序无关，只与联合索引建立的顺序有关。

即，

explain select * from tb_user where 
profession = '软件工程' 
and age = 31 
and status = '0';

-- 这两条SQL是一致的

explain select * from tb_user where 
age = 31 
and status = '0' 
and profession = '软件工程';

范围查询

联合索引中，出现范围查询(>,<)，范围查询右侧的列索引失效。

例如：

explain select * from tb_user where 
profession = '软件工程' 
and age > 30 
and status = '0';  -- status在>之后，所以该列索引失效

所以只有profession和age字段走了索引。

在业务允许的情况下，尽可能的使用类似于 >= 或 <= 这类的范围查询，而避免使用 > 或 <。

索引失效情况

索引列运算

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

例如，对phone字段进行函数运算，它的索引就会失效：

explain select * from tb_user where substring(phone,10,2) = '15';

字符串不加引号

explain select * from tb_user where 
profession = '软件工程' 
and age = 31 
and status = '0';

--  没有加引号的话，status字段的索引就会失效

explain select * from tb_user where 
profession = '软件工程' 
and age = 31 
and status = 0;

对于查询结果，没什么影响，但是数据库存在隐式类型转换，索引会失效。

模糊查询

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

例如：

explain select * from tb_user where profession like '软件%';
explain select * from tb_user where profession like '%工程';  -- 索引失效
explain select * from tb_user where profession like '%工%';   -- 索引失效

在like模糊查询中，在关键字后面加%，索引可以生效。而如果在关键字前面加了%，索引将会失效。

or连接条件

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

例如下面两条SQL语句：

explain select * from tb_user where id = 10 or age = 23;
explain select * from tb_user where phone = '17799990017' or age = 23;
-- age没有索引，其作为联合索引也不满足最左前缀法则

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

当or连接的条件，左右两侧字段都有索引时，索引才会生效。