用MySql的查询分析语法explain来优化查询和索引
http://hi.baidu.com/wtnzone/item/beb83840a4971af4dd0f6c77
數(shù)據(jù)庫最常見的操作就是查詢了，我們經(jīng)常要用"SELECT"語法對已有的表進行某種檢索，但是在實際應(yīng)用中，查詢前我們并不知道該查詢會如何運行、會使用多少時間、會涉及多少字段和記錄，每次輸入了SQL語句，點擊運行，然后慢慢等待結(jié)果的出現(xiàn)，好的查詢語句效率很高，而有時候也會遇到查詢緩慢，久久沒有運行完成的情況。
由于我們并不知道實際查詢的時候數(shù)據(jù)庫里發(fā)生了什么，數(shù)據(jù)庫軟件是怎樣掃描表、怎樣使用索引，因此我們能感知的就只有查詢運行的時間，而往往在數(shù)據(jù)規(guī)模不大時，查詢是瞬間的，因此在寫SQL語句時也就比較隨意，也很少使用索引來加速查詢的速度。不過一旦數(shù)據(jù)規(guī)模增大，比如百萬、千萬、幾億的時候，我們寫同樣的查詢語句卻發(fā)現(xiàn)窗口遲遲沒有結(jié)果，這個時候才知道數(shù)據(jù)規(guī)模已經(jīng)限制了我們自由查詢的速度。查詢優(yōu)化和索引也就顯得很重要了。
那么，能不能在查詢前就能預(yù)先估計查詢究竟要涉及多少行、使用哪些索引、運行多久呢？答案是可以的，MySql和SQL Server都提供了相應(yīng)的功能和語法來實現(xiàn)，下面用一個擁有兩千多萬條記錄的表來說明如何進行查詢分析。該表有一個訪問時間字段。
MySql提供了EXPLAIN語法用來進行查詢分析，在SQL語句前加一個"EXPLAIN"即可。比如我們要分析如下SQL語句，該語句獲取特定時間段的訪問記錄總數(shù)。
EXPLAIN
SELECT COUNT(*) FROM ××××××
WHERE
TIME_INT>=UNIX_TIMESTAMP('2010-03-01 18:00:00') AND?
TIME_INT<UNIX_TIMESTAMP('2010-03-01 18:15:00')
返回的結(jié)果如下
從分析結(jié)果可知，該查詢涉及3674行，用到了timeindex這個索引，using index說明該查詢只需要檢索索引即可完成。EXPLAIN中每一項的具體描述和表達(dá)的意義如下：（來自http://www.phpweblog.net/richard-dong/archive/2008/12/15/6173.aspx）
------------------------------
table | type | possible_keys | key | key_len | ref | rows | Extra
EXPLAIN列的解釋
table?
顯示這一行的數(shù)據(jù)是關(guān)于哪張表的
type?
這是重要的列，顯示連接使用了何種類型。從最好到最差的連接類型為const、eq_reg、ref、range、indexhe和ALL（后面有詳細(xì)說明）
possible_keys?
顯示可能應(yīng)用在這張表中的索引。如果為空，沒有可能的索引?？梢詾橄嚓P(guān)的域從WHERE語句中選擇一個合適的語句
key?
實際使用的索引。如果為NULL，則沒有使用索引。很少的情況下，MYSQL會選擇優(yōu)化不足的索引。這種情況下，可以在SELECT語句中使用USE INDEX（indexname）來強制使用一個索引或者用IGNORE INDEX（indexname）來強制MYSQL忽略索引
key_len?
使用的索引的長度。在不損失精確性的情況下，長度越短越好
ref?
顯示索引的哪一列被使用了，如果可能的話，是一個常數(shù)
rows?
MYSQL認(rèn)為必須檢查的用來返回請求數(shù)據(jù)的行數(shù)
Extra?
關(guān)于MYSQL如何解析查詢的額外信息。將在表4.3中討論，但這里可以看到的壞的例子是Using temporary和Using filesort，意思MYSQL根本不能使用索引，結(jié)果是檢索會很慢
extra列返回的描述的意義
Distinct?
一旦MYSQL找到了與行相聯(lián)合匹配的行，就不再搜索了
Not exists?
MYSQL優(yōu)化了LEFT JOIN，一旦它找到了匹配LEFT JOIN標(biāo)準(zhǔn)的行，就不再搜索了
Range checked for each
Record（index map:#）?
沒有找到理想的索引，因此對于從前面表中來的每一個行組合，MYSQL檢查使用哪個索引，并用它來從表中返回行。這是使用索引的最慢的連接之一
Using filesort?
看到這個的時候，查詢就需要優(yōu)化了。MYSQL需要進行額外的步驟來發(fā)現(xiàn)如何對返回的行排序。它根據(jù)連接類型以及存儲排序鍵值和匹配條件的全部行的行指針來排序全部行
Using index?
列數(shù)據(jù)是從僅僅使用了索引中的信息而沒有讀取實際的行動的表返回的，這發(fā)生在對表的全部的請求列都是同一個索引的部分的時候
Using temporary?
看到這個的時候，查詢需要優(yōu)化了。這里，MYSQL需要創(chuàng)建一個臨時表來存儲結(jié)果，這通常發(fā)生在對不同的列集進行ORDER BY上，而不是GROUP BY上
Where used?
使用了WHERE從句來限制哪些行將與下一張表匹配或者是返回給用戶。如果不想返回表中的全部行，并且連接類型ALL或index，這就會發(fā)生，或者是查詢有問題
不同連接類型的解釋（按照效率高低的順序排序）
system?
表只有一行：system表。這是const連接類型的特殊情況
const?
表中的一個記錄的最大值能夠匹配這個查詢（索引可以是主鍵或惟一索引）。因為只有一行，這個值實際就是常數(shù)，因為MYSQL先讀這個值然后把它當(dāng)做常數(shù)來對待
eq_ref?
在連接中，MYSQL在查詢時，從前面的表中，對每一個記錄的聯(lián)合都從表中讀取一個記錄，它在查詢使用了索引為主鍵或惟一鍵的全部時使用
ref?
這個連接類型只有在查詢使用了不是惟一或主鍵的鍵或者是這些類型的部分（比如，利用最左邊前綴）時發(fā)生。對于之前的表的每一個行聯(lián)合，全部記錄都將從表中讀出。這個類型嚴(yán)重依賴于根據(jù)索引匹配的記錄多少—越少越好
range?
這個連接類型使用索引返回一個范圍中的行，比如使用>或<查找東西時發(fā)生的情況
index?
這個連接類型對前面的表中的每一個記錄聯(lián)合進行完全掃描（比ALL更好，因為索引一般小于表數(shù)據(jù)）
ALL?
這個連接類型對于前面的每一個記錄聯(lián)合進行完全掃描，這一般比較糟糕，應(yīng)該盡量避免
------------------------------
弄明白了explain語法返回的每一項結(jié)果，我們就能知道查詢大致的運行時間了，如果查詢里沒有用到索引、或者需要掃描的行過多（比如>=幾十萬行），那么可以感到明顯的延遲。因此需要改變查詢方式或者新建索引。
比如沒有建索引，或者查詢寫得不好（沒有用到索引列），會造成如下掃描所有兩千多萬條記錄的查詢方案（type為"ALL"，rows有兩千多萬），這顯然是不可取的，運行的話至少需要一分鐘的時間。
而一旦使用了索引，情況會大大改變，如下
這個時候最多掃描2624條記錄，使用了索引timeindex，同時extra里有Using index，表明了列數(shù)據(jù)是從僅僅使用了索引中的信息而沒有讀取實際的行動的表返回的，查詢速度也成千上萬倍的提升，不到0.1秒。
因此MySql中的explain語法可以幫助我們改寫查詢，優(yōu)化表的結(jié)構(gòu)和索引的設(shè)置，從而最大地提高查詢效率。當(dāng)然，在大規(guī)模數(shù)據(jù)量時，索引的建立和維護的代價也是很高的，往往需要較長的時間和較大的空間，如果在不同的列組合上建立索引，空間的開銷會更大。因此索引最好設(shè)置在需要經(jīng)常查詢的字段中。
------------------------------
不僅是MySql，每個主流數(shù)據(jù)庫都有相應(yīng)的查詢分析的功能，比如SQL Server具有強大的圖形化分析功能，暫時還沒有深入研究，所以就放幾張圖吧。它不僅能仔細(xì)分析出查詢的細(xì)節(jié)，連CPU使用、IO消耗等等都能進行估計
=======http://my.oschina.net/phpnew/blog/151194
優(yōu)秀的sqlyog, 我深深地感到不安及自責(zé), 盜版用戶多年, 多少有點感覺過意不去, 希望富二代們能夠支持正版吧.
最近osc還在討論什么是php大牛, 以前看過帖子, 說得非常貼切. phper, 半個運維工程師, 半個dba, 半個前端設(shè)計, 半個js動畫, 半個市場營銷. 如果你的公司想發(fā)展, 請招一個phper, 全能型人才哪里找, 山東可以找藍(lán)翔, osc找phper.
回正題, 作為phper,當(dāng)然在dba方面也要熟悉, 本人基礎(chǔ)知識薄弱, 才疏學(xué)淺, 對sqlyog研究未盡深刻, 有錯誤的地方請指點.
Sqlyog 盜版機制做得還是不錯的, 官網(wǎng)都不提供旗艦版下載, 可"優(yōu)秀"的中國人更為強大, 這不v11.13都已經(jīng)完美兼容. 有需要的同學(xué)上這兒下載:?http://www.fenanr.com/read/112140.html
簡單的寫一句查詢語句, 然后點擊左上角那個執(zhí)行, 或者按F12, 結(jié)果頁將會顯示出數(shù)據(jù). 如果你使用過舊版, 發(fā)現(xiàn)數(shù)據(jù)顯示后, 是可以編輯的. 而新版本拋棄了這個默認(rèn)設(shè)置, 我個人覺得是非常合理的.我們先是想看看, 再決定是否修改.sqlyog這點人性化考慮非常細(xì)膩.
作為優(yōu)秀的編輯器, 總是需要思考用戶所想, 有時我們在編寫sql時, 是不是想它提示出字段名呢? sqlyog在這方面做得非常強大. 可以提示字段名, 函數(shù), 關(guān)鍵字,元素, 數(shù)據(jù)表,
我大概歸類了一下: f: 函數(shù).? c: 字段名. k:關(guān)鍵字.? 余下一種就是數(shù)據(jù)表. 這對于許多sql編寫者來說, 是非常方便的功能.
性能優(yōu)化才是互聯(lián)網(wǎng)技術(shù)人員的關(guān)鍵, 優(yōu)化得力可以讓速度翻倍, 那我們怎么知道一條sql性能如何呢? sqlyog可以快速為語句檢測一次解釋. 也就是explain的語法.?
執(zhí)行后配置文件頁將顯示出結(jié)果. 具體怎么看這表, soso吧.
在phpmyadmin中, 我們碰到個問題就是, 我希望可以一次性寫多條語句, 可以分開執(zhí)行. 而不需要清空編輯器. sqlyog就非常智能的解決了這個問題. 你可以在編輯器中寫無數(shù)條sql, 只要記得結(jié)束加分號.
鼠標(biāo)光標(biāo)所在的那一條, 將會被執(zhí)行. 也就是你點到哪, 就執(zhí)行哪一句. 這樣你就可以一條語句延伸N條test語句, 直觀地運行查看性能結(jié)果.?
無論多少條語句, 編寫的智能提示仍然有效.
常用的四條語句, 有時要完全寫出來, 還真不是件容易的事, 而在sqlyog中就容易了, 直接界面操作, 或者按快捷鍵.
?系統(tǒng)默認(rèn)釋放的sql, 可能跟你想像中的不太一樣, 或許不夠直觀, 特別在過程,聯(lián)表, 觸發(fā)器語句中, 格式化查詢后的效果會非常明顯.
當(dāng)在創(chuàng)建臨時表語句中, 會碰到許多里里外外的分號, 也就把sql給分隔了, 導(dǎo)致執(zhí)行失敗. sqlyog當(dāng)然不會犯這種低級錯誤, 而是需要把語句選擇起來執(zhí)行, 如圖片所示.
圖片中演示的是一次性將兩條語句執(zhí)行起來. 下面會出現(xiàn)二個結(jié)果頁. 分別代表每語句的結(jié)果. 這功能相信你不會錯過.
我想,sqlyog 更為強大的是歷史記錄功能, 非常明了的列表, 執(zhí)行時間, 執(zhí)行效率.
總結(jié)
以上是生活随笔為你收集整理的用MySql的查询分析语法explain来优化查询和索引的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： iBatis resultMap出错 T
- 下一篇： MongoDB 里面日期查询的问题