MySQL優化全攻略-相關數據庫命令

2024-07-24 12:55:14

字體：大中小

來源：轉載

供稿：網友

接下來我們要討論的是數據庫性能優化的另一方面，即運用數據庫服務器內建的工具輔助性能分析和優化。

　　 ▲ 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.devshed.com/server_side/mysql/optimize/
或者看看chinabyte的文章好了：
http://www.chinabyte.com/builder/detail.shtm?buiid=1012&parid=1

哈哈～從這點能不能看出來我是全心全意為大家服務的

上一篇：MySQL優化全攻略－服務器參數調整

下一篇：關于在 win2000 下安裝 mysql 的一些問題!