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

索引使用（上）

验证索引效率

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

在演示的时候，我们还是使用之前的一张表 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存在，那此时将不会使用到该索引；

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

即，

xexplain 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连接的条件，左右两侧字段都有索引时，索引才会生效。

• 数据分布影响
  

如果MySQL评估使用索引比全表更慢，则不使用索引。

MySQL在查询时，会评估使用索引的效率与走全表扫描的效率，如果走全表扫描更快，则放弃索引，走全表扫描。 因为索引是用来索引少量数据的，如果通过索引查询返回大批量的数据，则还不如走全表扫描来的快，此时索引就会失效。

SQL提示

SQL提示，是优化数据库的一个重要手段，简单来说，就是在SQL语句中加入一些人为的提示来达到优化操作的目的。

MySQL在外面查询的时候，如果有多个可能会使用到的索引，那么MySQL会自动选择一个索引进行使用，我们能不能在查询的时候，自己来指定使用哪个索引呢？ 答案是肯定的，此时就可以借助于MySQL的SQL提示来完成。

接下来，介绍一下SQL提示。

use index

建议MySQL使用哪一个索引完成此次查询（仅仅是建议，mysql内部还会再次进行评估）。

explain select * from tb_user use index(idx_user_pro)

where profession = '软件工程';

• ignore index
  

忽略指定的索引。

explain select * from tb_user ignore index(idx_user_pro)

where profession = '软件工程';

• force index
  

强制使用索引。

explain select * from tb_user force index(idx_user_pro)

where profession = '软件工程';

END