使用MySQL中的EXPLAIN解釋命令來檢查SQL

咱們看到許多客戶的系統由於SQL及數據庫設計的不好因此致使許多性能上的問題，這些問題很差解決，可是能夠採用一套簡單的策略來檢查生產系統，發現並糾正一些共性問題。

很顯然，您應該盡最大努力設計出最好的數據庫，使其有很好的索引並在應用程序中採用高質量的SQL查詢語句。可是，在不少時候，現實與設計仍是有很大的差別，這是由於網絡應用程序開發速度快，再加上更新速度也很快，因此，數據庫所鏈接的進程數也常常發生變化。

不幸的是，如今服務器運行速度很快，這些問題不容易察覺，只有當系統投入運行一段時間，隨着用戶和數據的增長，才發現問題。表中若只有10，000行的時候，任何系統都能運行的很好，可是，當表中有數百萬行而SQL又不好的時候，系統就會出現問題。隨着併發用戶數量增多，會發出更多的併發查詢，而這些查詢要閱讀數百萬行。

接下來發生的事就不盡人意了，由於服務器會運行的很慢，像蝸牛在爬，而每一個查詢要花好幾秒的時間才能完成任務，這樣絕不費力就能使網站垮掉。這就是所謂的「瓶頸」，指的是系統一直運行的很好，但忽然有一天跨了。現今，有不少系統都會出現這樣的問題。

要找出問題所在並不容易，可是能夠運用一些好的工具來幫忙查找問題。首先，最管用的工具就是slow log，但是，標準工具(mysqldumpslow)不會給出最重要的統計數據 – 已檢查的行數。要監控系統性能，這些所謂的重要的服務器統計數據根本就算不上是好數據。請注意，還有其它的好工具，如Percona的 pt-query-profiler就很管用。

當你發現SQL遇到問題，檢查出有不少行的時候，你能夠在這些SQL查詢中，運行EXPLAIN EXTENDED命令。儘管該命令輸出的內容比較複雜、難以理解，可是，你能夠經過網絡資源或像Percona這些工具的幫助，就能夠理解命令內容。

可是，若是是一些像咱們所看到的簡單查詢的話（只有單個查詢，不含子查詢，這些查詢因爲臨時表的存在可能會有不少行/表及聯接）輸出結果仍是容易解釋的。

檢查EXPLAIN EXTENDED的輸出內容（EXTENDED是比較重要的命令，由於該命令可展現許多額外信息），咱們會發現不少關鍵信息：Type這一列很重要，若是輸出結果是All或索引，它將會要求掃描全部的表或索引。

Keys這一列也很重要，由於它告訴你使用了哪一個索引，若是此處爲空，表示未使用任何索引，絕大多數狀況下，您需解決此問題。

Rows這一列告知您數據庫即將要閱讀的行數，固然，越少越好。從理論上來說，這些未閱讀的行數經閱讀以後，會被記錄到日誌中成爲已檢查的行數，可是實際將要閱讀的行數和EXPLAIN系統所記載的將要閱讀的行數可能會有差別，這是由於EXPLAIN系統的行數只是預估的行數。請注意此處不包括LIMIT，可是LIMIT不會使要閱讀的行數減小，尤爲是查詢中有排序要求的時候，更不會減小要閱讀的行數。

經過藉助在線資源及一些工具，您可更好地理解輸出的結果。您將發現哪些SQL執行的比較慢及根源是什麼，在此，您能夠更改SQL、更改索引甚至是更改數據庫設計以便提升系統性能。

（Authored by Steve Mushero / ChinaNetCloud CEO & CTO  本博客英文原文請點此查看）