用mysql的执行计划分析DATE_FORMAT函数对索引的影响

最近公司在代码评审时,在使用DATE_FORMAT函数的问题上有了点不同的观点。
具体DATE_FORMAT对索引会不会产生影响?哪种情况下会产生影响呢?
周末无事,通过mysql的执行计划测试一波

注意:本文中采用的数据库为mysql7,若使用mysql6及其他版本数据库可能测试结果不同

执行计划

执行计划就是展示Mysql如何执行一条Sql语句,包括Sql查询的顺序、是否使用索引、以及使用的索引信息等内容

展示如图

 id :

表示查询中select操作表的顺序,按顺序从大到依次执行
select_type :

该表示选择的类型,可选值有: SIMPLE(简单的),
type :

该属性表示访问类型,有很多种访问类型。
最常见的其中包括以下几种: ALL(全表扫描), index(索引扫描),range(范围扫描),ref (非唯一索引扫描),eq_ref(唯一索引扫描,),(const)常数引用, 访问速度依次由慢到快。
其中 : range(范围)常见与 between and …, 大于 and 小于这种情况。
提示 : 慢SQL是否走索引,走了什么索引,也就可以通过该属性查看了。
table :

表示该语句查询的表
possible_keys :

顾名思义,该属性给出了,该查询语句,可能走的索引,(如某些字段上索引的名字)这里提供的只是参考,而不是实际走的索引,也就导致会有possible_Keys不为null,key为空的现象。
key :

显示MySQL实际使用的索引,其中就包括主键索引(PRIMARY),或者自建索引的名字。
key_len :

表示索引所使用的字节数,
ref :

连接匹配条件,如果走主键索引的话,该值为: const, 全表扫描的话,为null值
rows :

扫描行数,也就是说,需要扫描多少行,采能获取目标行数,一般情况下会大于返回行数。通常情况下,rows越小,效率越高, 也就有大部分SQL优化,都是在减少这个值的大小。
注意: 理想情况下扫描的行数与实际返回行数理论上是一致的,但这种情况及其少,如关联查询,扫描的行数就会比返回行数大大增加)
Extra

这个属性非常重要,该属性中包括执行SQL时的真实情况信息,如上面所属,使用到的是”using where”,表示使用where筛选得到的值,常用的有: “Using temporary”: 使用临时表 “using filesort”: 使用文件排序

表语句及数据插入sql

 执行如下sql

explain select * from user where birth_date <= '2009-10-10';

 如图所示birth_date的索引生效了

原文地址:https://www.cnblogs.com/yangzailu/p/12526539.html