今天,數據庫的操做愈來愈成爲整個應用的性能瓶頸了,這點對於Web應用尤爲明顯。關於數據庫的性能,這並不僅是DBA才須要擔憂的事,而這更是咱們程序員須要去關注的事情。當咱們去設計數據庫表結構,對操做數據庫時(尤爲是查表時的SQL語句),咱們都須要注意數據操做的性能。這裏,咱們不會講過多的SQL語句的優化,而只是針對MySQL這一Web應用最多的數據庫mysql
1.explain(查看執行計劃):使用Explain關鍵字能夠模擬優化器執行SQL查詢語句,從而知道MySql是如何處理你的SQL語句的,分析你的查詢語句或是表結構的性能瓶頸。程序員
(1.)能幹嗎?sql
(2.)怎麼玩數據庫
1.Explain+SQL語句性能
2.執行計劃包含的信息優化
2.各名詞解釋spa
(1)id設計
一.第一種狀況blog
二.第二種狀況排序
三.第三種狀況
(2).select_type
一.有哪些
simple: 簡單的select查詢,查詢中不包括子查詢或者union
primary: 查詢中若包含任何複雜的子部分,最外層查詢則被標記爲
subQuery: 在select或where列表中包括子查詢
derived: 在from列表中包括的子查詢被標記爲derived。mysql會遞歸執行這些子查詢,把結果放在臨時表裏。
union: 若第二個select出如今union以後,則被標記爲union。若union包含在from子句的子查詢中,外層select將被標記爲derived
union result: 從union表中獲取的結果select。
查詢的類型,主要用於區別普通查詢,聯合查詢,子查詢等的複雜查詢
(3).type:訪問數據類型
一.有哪些值
從最好到最差依次是:
System>const>eq_ref>ref>range>index>All
通常來講,的保證查詢至少達到range級別,最好能達到ref
type類型 | 說明 |
All | 最壞的狀況,從頭至尾全表掃描 |
index | 和全表掃描同樣。只是掃描表的時候按照索引次序進行而不是行。主要優勢就是避免了排序, 可是開銷仍然很是大。如在Extra列看到Using index,說明正在使用覆蓋索引,只掃描索引的數據,它比按索引次序全表掃描的開銷要小不少 |
range | 範圍掃描,一個有限制的索引掃描。key 列顯示使用了哪一個索引。當使用=、 <>、>、>=、<、<=、IS NULL、<=>、BETWEEN 或者 IN 操做符,用常量比較關鍵字列時,可使用 range |
ref | 一種索引訪問,它返回全部匹配某個單個值的行。此類索引訪問只有當使用非惟一性索引或惟一性索引非惟一性前綴時纔會發生 |
eq_ref | 最多隻返回一條符合條件的記錄。使用惟一性索引或主鍵查找時會發生 (高效) |
const/system | 當主鍵放入where子句時,mysql把這個查詢轉爲一個常量(高效) |
null | 意味說mysql能在優化階段分解查詢語句,在執行階段甚至用不到訪問表或索引(高效) |
(4)possible_key
一:顯示可能應用在這張表中的索引,,一個或多個,查詢涉及到的字段上若存在索引,則該索引將被列出,但不必定被查詢實際使用
(5)key
一.實際使用的索引,若是爲null,則沒有使用索引
二.查詢中若使用了覆蓋索引,則該索引僅出如今key列表中
(6)key_len
一.表示索引中使用的字節數,可經過該列計算查詢中使用的索引的長度,在不損失精度的狀況下,長度越短越好。
二.key_len顯示的值爲索引字段的最大可能長度,並不是實際使用長度,即key_len是根據表定義計算而得,不是經過表內檢索出來的。
(7)ref
一.顯示索引的那一列被使用了,若是使用的話,是一個常數,那些列或常量被用於查找索引列的值
(8)rows
一. 根據表統計信息及索引選用狀況,大體估算出找到所需的記錄所須要讀取的行數
(9).Extra
額外信息。如using index,using filesort,using where 等