《Mysql學習MySQL優化全攻略-相關數據庫命令》要點：
本文介紹了Mysql學習MySQL優化全攻略-相關數據庫命令，希望對您有用。如果有疑問，可以聯系我們。

接下來我們要討論的是數據庫性能優化的另一方面,即運用數據庫服務器內建的工具輔助性能分析和優化.??
　　?▲?SHOW??
　　?執行下面這個命令可以了解服務器的運行狀態：??
mysql?>show?status;?
　　?該命令將顯示出一長列狀態變量及其對應的值,其中包括：被中止訪問的用戶數量,被中止的連接數量,嘗試連接的次數,并發連接數量最大值,以及其他許多有用的信息.這些信息對于確定系統問題和效率低下的原因是十分有用的.??
　　?SHOW命令除了能夠顯示出MySQL服務器整體狀態信息之外,它還能夠顯示出有關日志文件、指定數據庫、表、索引、進程和許可權限表的寶貴信息.請訪問http://www.mysql.com/doc/S/H/SHOW.html了解更多信息.??
　　?▲?EXPLAIN??
　　?EXPLAIN能夠分析SELECT命令的處理過程.這不僅對于決定是否要為表加上索引很有用,而且對于了解MySQL處理復雜連接的過程也很有用.??
　　?下面這個例子顯示了如何用EXPLAIN提供的信息逐步地優化連接查詢.(本例來自MySQL文檔,見http://www.mysql.com/doc/E/X/EXPLAIN.html.原文寫到這里似乎有點潦草了事,特加上此例.)??
　　?假定用EXPLAIN分析的SELECT命令如下所示：??
EXPLAIN?SELECT?tt.TicketNumber,?tt.TimeIn,?
??????tt.ProjectReference,?tt.EstimatedShipDate,?
??????tt.ActualShipDate,?tt.ClientID,?
??????tt.ServiceCodes,?tt.RepetitiveID,?
??????tt.CurrentProcess,?tt.CurrentDPPerson,?
??????tt.RecordVolume,?tt.DPPrinted,?et.COUNTRY,?
??????et_1.COUNTRY,?do.CUSTNAME?
????FROM?tt,?et,?et?AS?et_1,?do?
????WHERE?tt.SubmitTime?IS?NULL?
??????AND?tt.ActualPC?=?et.EMPLOYID?
??????AND?tt.AssignedPC?=?et_1.EMPLOYID?
??????AND?tt.ClientID?=?do.CUSTNMBR;?

　　?SELECT命令中出現的表定義如下：??
　　?※表定義??
表?列?列類型??
tt?ActualPC?CHAR(10)??
tt?AssignedPC?CHAR(10)??
tt?ClientID?CHAR(10)??
et?EMPLOYID?CHAR(15)??
do?CUSTNMBR?CHAR(15)??

　?※索引??
表?索引??
tt?ActualPC??
tt?AssignedPC??
tt?ClientID??
et?EMPLOYID?(主鍵)??
do?CUSTNMBR?(主鍵)??
　　?※tt.ActualPC值分布不均勻??
　　?在進行任何優化之前,EXPLAIN對SELECT執行分析的結果如下：??
table?type?possible_keys????????key?key_len?ref?rows?Extra?
et??ALL?PRIMARY???????????NULL?NULL??NULL?74?
do??ALL?PRIMARY???????????NULL?NULL??NULL?2135?
et_1?ALL?PRIMARY???????????NULL?NULL??NULL?74?
tt??ALL?AssignedPC,ClientID,ActualPC?NULL?NULL??NULL?3872?
???range?checked?for?each?record?(key?map:?35)?

　　?每一個表的type都是ALL,它表明MySQL為每一個表進行了完全連接!這個操作是相當耗時的,因為待處理行的數量達到每一個表行數的乘積!即,這里的總處理行數為74?*?2135?*?74?*?3872?=?45,268,558,720.??
　　?這里的問題之一在于,如果數據庫列的聲明不同,MySQL(還)不能有效地運用列的索引.在這個問題上,VARCHAR和CHAR是一樣的,除非它們聲明的長度不同.由于tt.ActualPC聲明為CHAR(10),而et.EMPLOYID聲明為CHAR(15),因此這里存在列長度不匹配問題.??
　　?為了解決這兩個列的長度不匹配問題,用ALTER?TABLE命令把ActualPC列從10個字符擴展到15字符,如下所示：??
mysql?>?ALTER?TABLE?tt?MODIFY?ActualPC?VARCHAR(15);?

　　?現在tt.ActualPC和et.EMPLOYID都是VARCHAR(15)了,執行EXPLAIN進行分析得到的結果如下所示：??
table?type??possible_keys??key???key_len?ref?????rows??Extra?
tt??ALL??AssignedPC,ClientID,ActualPC?NULL?NULL?NULL?3872??where?used?
do??ALL??PRIMARY?????NULL??NULL??NULL????2135?
???range?checked?for?each?record?(key?map:?1)?
et_1?ALL??PRIMARY?????NULL??NULL??NULL????74?
???range?checked?for?each?record?(key?map:?1)?
et??eq_ref?PRIMARY?????PRIMARY?15???tt.ActualPC?1?

　　?這還算不上完美,但已經好多了(行數的乘積現在少了一個系數74).現在這個SQL命令執行大概需要數秒鐘時間.??
　　?為了避免tt.AssignedPC?=?et_1.EMPLOYID以及tt.ClientID?=?do.CUSTNMBR比較中的列長度不匹配,我們可以進行如下改動：??
mysql?>?ALTER?TABLE?tt?MODIFY?AssignedPC?VARCHAR(15),?
???????????MODIFY?ClientID??VARCHAR(15);?

　　?現在EXPLAIN顯示的結果如下：??
table?type??possible_keys??key???key_len?ref??????rows???Extra?
et??ALL??PRIMARY?????NULL??NULL??NULL??????74?
tt??ref??AssignedPC,ClientID,ActualPC?ActualPC?15?et.EMPLOYID?52?where?used?
et_1?eq_ref?PRIMARY?????PRIMARY?15???tt.AssignedPC?1?
do??eq_ref?PRIMARY?????PRIMARY?15???tt.ClientID??1?

　　?這個結果已經比較令人滿意了.?
　　?余下的問題在于,默認情況下,MySQL假定tt.ActualPC列的值均勻分布,而事實上tt表的情況并非如此.幸而,我們可以很容易地讓MySQL知道這一點：??
shell?>?myisamchk?--analyze?PATH_TO_MYSQL_DATABASE/tt?
shell?>?mysqladmin?refresh?

　　?現在這個連接操作已經非常理想,EXPLAIN分析的結果如下：??
table?type??possible_keys??key???key_len?ref??????rows??Extra?
tt??ALL??AssignedPC,ClientID,ActualPC?NULL?NULL?NULL??3872??where?used?
et??eq_ref?PRIMARY?????PRIMARY?15???tt.ActualPC??1?
et_1?eq_ref?PRIMARY?????PRIMARY?15???tt.AssignedPC?1?
do??eq_ref?PRIMARY?????PRIMARY?15???tt.ClientID??1?

　　?▲?OPTIMIZE??
　　?OPTIMIZE能夠恢復和整理磁盤空間以及數據碎片,一旦對包含變長行的表進行了大量的更新或者刪除,進行這個操作就非常有必要了.OPTIMIZE當前只能用于MyISAM和BDB表.??
　　?結束語：從編譯數據庫服務器開始、貫穿整個管理過程,能夠改善MySQL性能的因素實在非常多,本文只涉及了其中很小的一部分.盡管如此,我們希望本文討論的內容能夠對你有所幫助.??
//copy者注：?

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/3633.html