用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的索引生效了