接下來我們要討論的是數(shù)據(jù)庫性能優(yōu)化的另一方面，即運用數(shù)據(jù)庫服務(wù)器內(nèi)建的工具輔助性能分析和優(yōu)化。  
　　 ▲ SHOW  
　　 執(zhí)行下面這個命令可以了解服務(wù)器的運行狀態(tài)：  
mysql >show status; 
　　 該命令將顯示出一長列狀態(tài)變量及其對應(yīng)的值，其中包括：被中止訪問的用戶數(shù)量，被中止的連接數(shù)量，嘗試連接的次數(shù)，并發(fā)連接數(shù)量最大值，以及其他許多有用的信息。這些信息對于確定系統(tǒng)問題和效率低下的原因是十分有用的。  
　　 SHOW命令除了能夠顯示出MySQL服務(wù)器整體狀態(tài)信息之外，它還能夠顯示出有關(guān)日志文件、指定數(shù)據(jù)庫、表、索引、進(jìn)程和許可權(quán)限表的寶貴信息。請訪問http://www.mysql.com/doc/S/H/SHOW.html了解更多信息。  
　　 ▲ EXPLAIN  
　　 EXPLAIN能夠分析SELECT命令的處理過程。這不僅對于決定是否要為表加上索引很有用，而且對于了解MySQL處理復(fù)雜連接的過程也很有用。  
　　 下面這個例子顯示了如何用EXPLAIN提供的信息逐步地優(yōu)化連接查詢。（本例來自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命令中出現(xiàn)的表定義如下：  
　　 ※表定義  
表 列 列類型  
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值分布不均勻  
　　 在進(jìn)行任何優(yōu)化之前，EXPLAIN對SELECT執(zhí)行分析的結(jié)果如下：  
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為每一個表進(jìn)行了完全連接！這個操作是相當(dāng)耗時的，因為待處理行的數(shù)量達(dá)到每一個表行數(shù)的乘積！即，這里的總處理行數(shù)為74 * 2135 * 74 * 3872 = 45,268,558,720。  
　　 這里的問題之一在于，如果數(shù)據(jù)庫列的聲明不同，MySQL（還）不能有效地運用列的索引。在這個問題上，VARCHAR和CHAR是一樣的，除非它們聲明的長度不同。由于tt.ActualPC聲明為CHAR(10)，而et.EMPLOYID聲明為CHAR(15)，因此這里存在列長度不匹配問題。  
　　 為了解決這兩個列的長度不匹配問題，用ALTER TABLE命令把ActualPC列從10個字符擴展到15字符，如下所示：  
mysql > ALTER TABLE tt MODIFY ActualPC VARCHAR(15); 

　　 現(xiàn)在tt.ActualPC和et.EMPLOYID都是VARCHAR(15)了，執(zhí)行EXPLAIN進(jìn)行分析得到的結(jié)果如下所示：  
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 

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

　　 現(xiàn)在EXPLAIN顯示的結(jié)果如下：  
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 

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

　　 現(xiàn)在這個連接操作已經(jīng)非常理想，EXPLAIN分析的結(jié)果如下：  
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能夠恢復(fù)和整理磁盤空間以及數(shù)據(jù)碎片，一旦對包含變長行的表進(jìn)行了大量的更新或者刪除，進(jìn)行這個操作就非常有必要了。OPTIMIZE當(dāng)前只能用于MyISAM和BDB表。  
　　 結(jié)束語：從編譯數(shù)據(jù)庫服務(wù)器開始、貫穿整個管理過程，能夠改善MySQL性能的因素實在非常多，本文只涉及了其中很小的一部分。盡管如此，我們希望本文討論的內(nèi)容能夠?qū)δ阌兴鶐椭?nbsp; 
//copy者注： 
  時間不夠，所以格式上有點問題～～，請大家看詳細(xì)的英文原文：http://www.devshed.com/Server_Side/MySQL/Optimize/ 
或者看看chinabyte的文章好了： 
http://www.chinabyte.com/builder/detail.shtm?buiid=1012&parid=1 
哈哈～從這點能不能看出來我是全心全意為大家服務(wù)的

最新評論