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