MySQL優化全攻略-相關數據庫命令
發表於 : 2011-03-09 22:32:57
http://blog.itcert.org/archives/1156
接下來我們要討論的是數據庫性能優化的另一方面，即運用數據庫服務器內建的工具輔助性能分析和優化。
▲ 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.ht ... 這裡似乎有點潦草了事，特加上此例。）
假定用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.devshed.com/Server_Side/MySQL/Optimize/
或者看看chinabyte的文章好了：
http://www.chinabyte.com/builder/detail ... 12&parid=1
哈哈～從這點能不能看出來我是全心全意為大家服務的
接下來我們要討論的是數據庫性能優化的另一方面，即運用數據庫服務器內建的工具輔助性能分析和優化。
▲ 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.ht ... 這裡似乎有點潦草了事，特加上此例。）
假定用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.devshed.com/Server_Side/MySQL/Optimize/
或者看看chinabyte的文章好了：
http://www.chinabyte.com/builder/detail ... 12&parid=1
哈哈～從這點能不能看出來我是全心全意為大家服務的