mysql 中的explain關鍵字

摘要： mysql優化在實際的開發中是很重要，有很多可以評估自己寫的sql的質量與效率，mysql為我們提供了一個輔助武器explain，它向我們展示了mysql接收到一條sql語句的執行計劃，根絕explain返回的結果可以知道sql寫的怎樣, demo資料庫 建表語句 CREATE T...

mysql優化在實際的開發中是很重要，有很多可以評估自己寫的sql的質量與效率，mysql為我們提供了一個輔助武器explain，它向我們展示了mysql接收到一條sql語句的執行計劃，根絕explain返回的結果可以知道sql寫的怎樣,

demo資料庫

建表語句

CREATE TABLE test (
idINT(11) NOT NULL AUTO_INCREMENT,
uname VARCHAR(255),
age int,
PRIMARY KEY (id)
);

alter table test add index uname_index(uname);

複製程式碼

表中資料如下

id	uname	age
1	lxh	24
3	zhangsan	23
10	sdsx	12
11	x33	35

explain的關鍵字有很多，此處只講解最關鍵的type，key，rows

type

型別，官方全程“join type”,意思是“連線型別”，注意這裡不是字面意思量表之間的連結，確切說是資料庫引擎查詢表的一種方式，在《高效能mysql》一書中作者更是覺得稱呼它為訪問型別更貼切一些；

type的型別達到了14種之多，這裡只記錄和理解最重要且經常遇見的六種型別，它們分別是all,index,range,ref,eq_ref，const。從左到右，它們的效率依次是增強的

all

全表掃描，如果只是查詢一個數據項的sql出現了all型別，代表sql處於一種最原聲的狀態，有很大的優化空間，就好比一萬個人中找一個人，只能挨個找一遍 以test表為例

index

另一種方式的全表掃描，只不過是按照索引的順序，

ref

查詢條件列使用了索引而且不為主鍵和unique,意思就是雖然使用了索引，但該索引列的值並不唯一，有重複 比如，test表的索引是 uname

eq_ref

ref_eq 與 ref相比牛的地方是，它知道這種型別的查詢結果集只有一個,使用了主鍵或者唯一性索引進行查詢時， 下面這兩張表一張學生表，一張成績表，成績表裡的學生id，t_id,就是使用了主鍵

-- 建表語句
create table ref_stu2 (
idINT(11) NOT NULL AUTO_INCREMENT,
uname VARCHAR(255),
ageVARCHAR(255),
PRIMARY KEY (id)
);

create table ref_score2 (
idINT(11) NOT NULL AUTO_INCREMENT,
stu_id int(11) not null,
scoreint(11),
PRIMARY KEY (id)
 
);

explain select * from ref_stu2 stu, ref_score2 sc where stu.id = sc.stu_id;
複製程式碼

輸出結果

id	select_type	table	partitions	type	possible_keys	key	key_len	ref	rows	filtered	Extra
1	SIMPLE	stu	NULL	ALL	PRIMARY	NULL	NULL	NULL	1	100	NULL
1	SIMPLE	sc	NULL	eq_ref	uk_score_stuid	uk_score_stuid	4	ofollow,noindex">lxhtest.stu.id	1	100	NULL

const

將一個主鍵放置到where後面作為條件查詢，mysql優化器就能把這次查詢優化轉化為一個常量

explain select * from ref_stu2 stu where stu.id = 1;
複製程式碼

執行結果如下

id	select_type	table	partitions	type	possible_keys	key	key_len	ref	rows	filtered	Extra
1	SIMPLE	stu	null	const	PRIMARY	PRIMARY	4	const	1	100	null

key

查詢使用到的索引，type型別為index_merge（查詢使用了兩個以上的索引）時，這裡可能出現兩個以上的索引，其他的select_type這裡只會出現一個。

rows

這裡是執行計劃中估算的掃描行數，不是精確值,值越小，代表效率越高

索引覆蓋

覆蓋索引（covering index）指一個查詢語句的執行只用從索引中就能夠取得，不必從資料表中讀取

參考 SQL/">MySQL SQL 優化之覆蓋索引

關於like關鍵字是否用到索引

總結：like關鍵字是否使用索引的前提是做字首原則，即‘x’和‘x%’是使用索引的，他們的執行計劃中type都是range，rows都是比表的行數少的，而其他兩個type都是index，這種情況叫，全索引掃描，具體介紹如下， 如果模糊查詢時，查詢是否包含某個字串，可以採用locate函式， select * from test where locate("x",uname); 查詢test表中uname欄位，含有字串‘x’的資料。

mysql 全表掃描、全索引掃描、索引覆蓋(覆蓋索引)

full index scan：全索引掃描，查詢時，遍歷索引樹來獲取資料行。如果資料不是密集的會產生隨機IO 在執行計劃中是Type列，index

full table scan：通過讀物理表獲取資料，順序讀磁碟上的檔案。這種情況會順序讀磁碟上的檔案。 在執行計劃中是Type列，all

covering index：覆蓋索引，如果where條件的列和返回的資料在一個索引中，那麼不需要回查表，那麼就叫覆蓋索引。 在執行計劃中是extra那一列，using index

full index scan vs full table scan

全索引掃描一般情況下比全表掃描好，但一定不是絕對的

大多數資料是存在磁碟上的，讀取磁碟的次數是影響效率的關鍵。 由於索引掃描後要利用索引中的指標去逐一訪問記錄，假設每個記錄都使用索引訪問，則讀取磁碟的次數是查詢包含的記錄數T； 如果表掃描則讀取磁碟的次數是儲存記錄的塊數B； 如果T>B 的話索引就沒有優勢了，對於大多數資料庫來說，這個比例是10%（oracle，postgresql等），最終執行的時候，先對結果數量估算，如果小於（T<B）這個比例用索引，大於的話即直接表掃描所以結果也就不一定咯。

引用網上的一個例子 已知如下資訊： 假設一張表含有10萬行資料--------100000行 我們要讀取其中20%(2萬)行資料----20000行 表中每行資料大小80位元組----------80bytes 資料庫中的資料塊大小8K----------8000bytes 所以有以下結果： 每個資料塊包含100行資料---------100行（資料塊大小/每行資料的大小 8000/80 ） 這張表一共有1000個數據塊--------1000塊(資料總條數/每個塊包含的資料個數 100000/100)

背後的故事：

通過索引讀取20000行資料 = 約20000個table access by rowid = 需要處理20000個塊來執行這個查詢（通過索引去讀資料，在索引中找到一個鍵值，然後這個鍵值對應的rowid去讀表資料，rowid只對應一條記錄，所以讀一個塊也只是為了找到對應rowid的那條記錄，所以一次在一個塊中只讀一條記錄） 而如果是全表掃描呢，這個表一共是1000塊，也就1000次讀取，採用後者明顯效率高。

小計：最近在看mongo，發現原來mongo裡也有這個關鍵字，哈哈，看來是通用的啊

參考連結： mysql中explain的type的解釋 你的like語句為啥沒索引