接下來我們要討論的是數(shù)據(jù)庫性能優(yōu)化的另一方面，即運(yùn)用數(shù)據(jù)庫服務(wù)器內(nèi)建的工具輔助性能分析和優(yōu)化。
▲ SHOW
執(zhí)行下面這個命令可以了解服務(wù)器的運(yùn)行狀態(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。原文寫到這里似乎有點(diǎn)潦草了事，特加上此例。）
假定用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)耗時的，因?yàn)榇幚硇械臄?shù)量達(dá)到每一個表行數(shù)的乘積！即，這里的總處理行數(shù)為74 * 2135 * 74 * 3872 = 45,268,558,720。
這里的問題之一在于，如果數(shù)據(jù)庫列的聲明不同，MySQL（還）不能有效地運(yùn)用列的索引。在這個問題上，VARCHAR和CHAR是一樣的，除非它們聲明的長度不同。由于tt.ActualPC聲明為CHAR(10)，而et.EMPLOYID聲明為CHAR(15)，因此這里存在列長度不匹配問題。
為了解決這兩個列的長度不匹配問題，用ALTER TABLE命令把ActualPC列從10個字符擴(kuò)展到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列的值均勻分布，而事實(shí)上tt表的情況并非如此。幸而，我們可以很容易地讓MySQL知道這一點(diǎn)：
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性能的因素實(shí)在非常多，本文只涉及了其中很小的一部分。盡管如此，我們希望本文討論的內(nèi)容能夠?qū)δ阌兴鶐椭?nbsp;
//copy者注：
時間不夠，所以格式上有點(diǎn)問題～～，請大家看詳細(xì)的英文原文：http://www.devshed.com/Server_Side/MySQL/Optimize/
或者看看chinabyte的文章好了：
http://www.chinabyte.com/builder/detail.shtm?buiid=1012&parid=1
哈哈～從這點(diǎn)能不能看出來我是全心全意為大家服務(wù)的
