必须知道的SQL语句不走索引时的排查利器

前言：

在索引优化时，常常会看到的一句话：若是索引字段出现隐式字符集转换的话，那么索引将失效，进而转为全表扫描，查询效率将大大下降，要避免出现隐式字符集转换；html

在此我想问问同窗们：

你们知道为何隐式字符集转换会致使索引失效吗？mysql
实际场景中有没有遇到过隐式字符集转换致使索引失效的场景，具体排查的过程；sql

本文主线：

由上面的两个问题牵引出了本文的主线；微信

简单描述下隐式字符集转换致使索引失效的缘由网络
而后模拟实际场景排查隐式字符集转换致使索引失效的过程数据结构

隐式字符集转换致使索引失效的缘由

MySQL索引的数据结构是 B+Tree，想要走索引查询必需要知足其 最左前缀原则 ，不然没法经过索引树进行查找，只能进行全表扫描；函数

例如：下面的这个SQL因为在 索引字段 上使用函数进行运算，致使索引失效工具

select * from t_user where SUBSTR(name, 1, 2) = '李彤'

上面的这个SQL怎么改造才能使索引生效呢？以下所示：性能

select * from t_user where name like '李彤%'

经过上面的小例子能够知道，若是在索引字段上使用函数运算，则会致使索引失效，而索引字段的 隐式字符集转换 因为MySQL会自动的在索引字段上加上 转换函数 ，进而会致使索引失效；学习

那接下来咱们就经过模拟的实际场景来具体看看是否是因为MySQL自动给加上了转换函数而致使索引失效的；

模拟场景 + 问题排查

因为致使索引失效的缘由有不少，若是本身写的SQL怎么看都没问题，可是经过查看执行计划发现就是没有走索引查询，此时就会让不少人陷入困境，这究竟是怎么致使的呢？

此时本文重点将要讲述的工具就要闪亮登场啦： explain extended + show warnings ；

使用这个工具能够将执行的SQL语句的一些扩展信息展现出来，这些扩展信息就包括：MySQL优化时可能会添加上字符集转换函数，使得字符集不匹配的SQL能够正确执行下去；

下面就来具体聊聊 explain extended + show warnings 的使用；

模拟隐式字符集转换的场景：

首先建立两个字符集不同的表：

CREATE TABLE `t_department` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `de_no` varchar(32) NOT NULL,
  `info` varchar(200) DEFAULT NULL,
  `de_name` varchar(200) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `index_de_no` (`de_no`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=12 DEFAULT CHARSET=utf8mb4;


CREATE TABLE `t_employees` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `em_no` varchar(32) NOT NULL,
  `de_no` varchar(32) NOT NULL,
  `age` int(11) DEFAULT NULL,
  `info` varchar(200) DEFAULT NULL,
  `em_name` varchar(200) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `index_em_no` (`de_no`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=12 DEFAULT CHARSET=utf8;

而后使用存储过程构造数据：

# 若是存储过程存在则删除 
DROP PROCEDURE IF EXISTS proc_initData;

DELIMITER $
# 建立存储过程
CREATE PROCEDURE proc_initData()
BEGIN
    DECLARE i INT  DEFAULT 1;
    WHILE i<=30 DO
        # 新增数据
        INSERT INTO t_employees ( em_no, de_no, info, em_name , age) VALUES ( CONCAT('001', i), '003', 'test11', 'test2', i ); #执行的sql语句
        SET i = i+1;
    END WHILE;
END $

# 调用存储过程
CALL proc_initData();

注意：在构造数据时，记得将 t_employees 表中的 de_no 字段值构造的 离散些 ，由于若是索引字段值的 区分度很低 的话，那么MyQSL优化器经过采样统计分析时，发现索引查询和全表扫描性能差很少，就会直接进行全表扫描了；

索引失效的查询SQL语句：

将表和数据构造完后，咱们使用SQL语句进行查询下，而后再看看其执行计划；

explain 
select * from t_department a LEFT JOIN  t_employees b on a.de_no = b.de_no where a.id = 16

其执行计划以下：

发现 t_employees 表中的 de_no 字段有索引，可是没有走索引查询，type=ALL 走的全表扫描，可是经过查看SQL语句发现其没有问题呀，表面看上去都是知足走索引查询的条件呀，排查到这发现遇到了困境，苦恼啊！

还好，经过在网络世界上遨游，最终发现了 explain extended + show warnings 利器，利用它快速发现了索引失效的根本缘由，而后快速找到了解决方案；

下面就来聊聊这个利器的具体使用，开森！

使用利器快速排查问题：

注意：explain 后面跟的关键字 EXTENDED（扩展信息）在MySQL5.7及以后的版本中废弃了，可是该语法仍被识别为向后兼容，因此在5.7版本及后续版本中，能够不用在 explain 后面添加 EXTENDED 了；

EXTENDED关键字的具体查阅资料：https://dev.mysql.com/doc/refman/5.7/en/explain-extended.html

具体使用方法以下：

①、首先在MySQL的可视化工具中打开一个 命令列介面 ：工具 --> 命令列介面

②、而后输入下面的SQL并按回车：

explain EXTENDED
select * from t_department a LEFT JOIN  t_employees b on a.de_no = b.de_no where a.id = 4019;

③、而后紧接着输入命令 show warnings; 并回车，会出现以下图所示内容：

经过展现出的执行SQL扩展信息，发现MySQL在字符集不一致时自动添加上字符集转换函数，由于是在 索引字段 de_no 上添加的转换函数，因此就致使了索引失效；

而若是咱们没看扩展信息的话，那么可能直到咱们查看表结构的时候才会发现是因为字符集不一致致使的，这样就会花费不少的时间；

扩展：隐式类型转换

我们聊完上面的隐式字符集转换致使索引失效的状况，再来简单聊聊另外一种 隐式类型转换 致使索引失效的状况；

隐式类型转换：简单的说就是字段的类型与其赋值的类型不一致时会进行隐式的转换；

小例以下：

select * from t_employees where em_name = 123;

上面的SQL中 em_name 为索引字段，字段类型是 varchar，为其赋 int 类型的值时，会发现索引失效，这里也能够经过 explain extended + show warnings 查看，会发现以下图所示内容：

至此本文进入结尾，在此再说明下，上文中测试时使用的MySQL版本都是 5.7 ；

♡ 点赞 + 评论 + 转发哟

若是本文对您有帮助的话，请挥动下您爱发财的小手点下赞呀，您的支持就是我不断创做的动力，谢谢啦！

您能够微信搜索 【木子雷】 公众号，大量Java学习干货文章，您能够来瞧一瞧哟！