前些天發現了一個巨牛的人工智能學習網站，通俗易懂，風趣幽默，忍不住分享一下給大家。點擊跳轉到教程。

引言：

實際項目開發中，由于我們不知道實際查詢的時候數據庫里發生了什么事情，數據庫軟件是怎樣掃描表、怎樣使用索引的，因此，我們能感知到的就只有

sql 語句運行的時間，在數據規模不大時，查詢是瞬間的，因此，在寫 sql 語句的時候就很少考慮到性能的問題。但是當數據規模增大，如千萬、億的時候，我們運

行同樣的 sql 語句時卻發現遲遲沒有結果，這個時候才知道數據規模已經限制了我們查詢的速度。所以，查詢優化和索引也就顯得很重要了。

問題：

當我們在查詢前能否預先估計查詢究竟要涉及多少行、使用哪些索引、運行時間呢？答案是能的，mysql 提供了相應的功能和語法來實現該功能。

分析：

MySql 提供了 EXPLAIN 語法用來進行查詢分析，在 SQL 語句前加一個“EXPLAIN”即可。比如我們要分析如下 SQL 語句：

explain select * from table where table.id = 1

運行上面的 sql 語句后你會看到，下面的表頭信息：

table | type | possiblekeys | key | keylen | ref | rows | Extra

EXPLAIN 列的解釋

table
顯示這一行的數據是關于哪張表的

type
這是重要的列，顯示連接使用了何種類型。從最好到最差的連接類型為 const、eq_reg、ref、range、indexhe 和 ALL

說明：不同連接類型的解釋（按照效率高低的順序排序）

system：表只有一行：system 表。這是 const 連接類型的特殊情況。

const ：表中的一個記錄的最大值能夠匹配這個查詢（索引可以是主鍵或惟一索引）。因為只有一行，這個值實際就是常數，因為 MYSQL 先讀這個值然后把它當做常數來對待。

eq_ref：在連接中，MYSQL 在查詢時，從前面的表中，對每一個記錄的聯合都從表中讀取一個記錄，它在查詢使用了索引為主鍵或惟一鍵的全部時使用。

ref：這個連接類型只有在查詢使用了不是惟一或主鍵的鍵或者是這些類型的部分（比如，利用最左邊前綴）時發生。對于之前的表的每一個行聯合，全部記錄都將從表中讀出。這個類型嚴重依賴于根據索引匹配的記錄多少—越少越好。

range：這個連接類型使用索引返回一個范圍中的行，比如使用>或<查找東西時發生的情況。

index：這個連接類型對前面的表中的每一個記錄聯合進行完全掃描（比 ALL 更好，因為索引一般小于表數據）。

ALL：這個連接類型對于前面的每一個記錄聯合進行完全掃描，這一般比較糟糕，應該盡量避免。

possible_keys
顯示可能應用在這張表中的索引。如果為空，沒有可能的索引。可以為相關的域從 WHERE 語句中選擇一個合適的語句

key
實際使用的索引。如果為 NULL，則沒有使用索引。很少的情況下，MYSQL 會選擇優化不足的索引。這種情況下，可以在 SELECT 語句中使用 USE INDEX（indexname）來強制使用一個索引或者用 IGNORE INDEX（indexname）來強制 MYSQL 忽略索引

key_len
使用的索引的長度。在不損失精確性的情況下，長度越短越好

ref
顯示索引的哪一列被使用了，如果可能的話，是一個常數

rows
MYSQL 認為必須檢查的用來返回請求數據的行數

Extra
關于 MYSQL 如何解析查詢的額外信息。將在表 4.3 中討論，但這里可以看到的壞的例子是 Using temporary 和 Using filesort，意思 MYSQL 根本不能使用索引，結果是檢索會很慢

說明：extra 列返回的描述的意義

Distinct ：一旦 mysql 找到了與行相聯合匹配的行，就不再搜索了。

Not exists ：mysql 優化了 LEFT JOIN，一旦它找到了匹配 LEFT JOIN 標準的行，就不再搜索了。

Range checked for each Record（index map:#） ：沒有找到理想的索引，因此對從前面表中來的每一個行組合，mysql 檢查使用哪個索引，并用它來從表中返回行。這是使用索引的最慢的連接之一。

Using filesort ：看到這個的時候，查詢就需要優化了。mysql 需要進行額外的步驟來發現如何對返回的行排序。它根據連接類型以及存儲排序鍵值和匹配條件的全部行的行指針來排序全部行。

Using index ：列數據是從僅僅使用了索引中的信息而沒有讀取實際的行動的表返回的，這發生在對表的全部的請求列都是同一個索引的部分的時候。

Using temporary ：看到這個的時候，查詢需要優化了。這里，mysql 需要創建一個臨時表來存儲結果，這通常發生在對不同的列集進行 ORDER BY 上，而不是 GROUP BY 上。

Where used ：使用了 WHERE 從句來限制哪些行將與下一張表匹配或者是返回給用戶。如果不想返回表中的全部行，并且連接類型 ALL 或 index，這就會發生，或者是查詢有問題。

因此，弄明白了 explain 語法返回的每一項結果，我們就能知道查詢大致的運行時間了，如果查詢里沒有用到索引、或者需要掃描的行過多，那么可以感到明顯的延遲。因此需要改變查詢方式或者新建索引。mysql 中的 explain 語法可以幫助我們改寫查詢，優化表的結構和索引的設置，從而最大地提高查詢效率。當然，在大規模數據量時，索引的建立和維護的代價也是很高的，往往需要較長的時間和較大的空間，如果在不同的列組合上建立索引，空間的開銷會更大。因此索引最好設置在需要經常查詢的字段中。

?

?

轉載:http://blog.csdn.net/u012990533/article/details/45643509

?