解決MySQL CPU佔用100%的經驗總結 轉

解決MySQL CPU佔用100%的經驗總結  

朋友主機 (Windows 2003 + IIS + PHP + MySQL) 近來 MySQL 服務進程 (MySQLd-nt.exe) CPU 佔用率總為 100% 高居不下。此主機有10個左右的 database，分別給十個網站調用。據朋友測試，導致 MySQLd-nt.exe CPU 佔用奇高的是網站A，一旦在 IIS 中將此網站停止服務，CPU 佔用就降下來了。一啟用，則馬上上升。

　　MySQL CPU 佔用 100% 的解決過程

　　今天早上仔細檢查了一下。目前此網站的七日平均日 IP 為2000，PageView 為 3萬左右。網站A 用的 database
目前有39個表，記錄數 60.1萬條，占空間 45MB。按這個資料，MySQL 不可能佔用這麼高的資源。

　　於是在伺服器上運行命令，將 MySQL 當前的環境變數輸出到檔案 output.txt：
d:/web/MySQL> MySQLd.exe --help >output.txt

　　發現 tmp_table_size 的值是預設的 32M，於是修改 My.ini，將 tmp_table_size 賦值到 200M:
d:/web/MySQL> notepad c:/windows/my.ini
[MySQLd]
tmp_table_size=200M

　　然後重啟 MySQL 服務。CPU 佔用有輕微下降，以前的CPU 佔用波形圖是 100% 一根直線，現在則在 97%~100%
之間起伏。這表明調整 tmp_table_size 參數對 MySQL 效能提升有改善作用。但問題還沒有完全解決。

　　於是進入 MySQL 的 shell 命令列，調用 show processlist， 查看當前 MySQL 使用頻繁的 sql 語句：
MySQL> show processlist;

　　反覆調用此命令（每秒刷兩次），發現網站 A 的兩個 SQL 陳述式經常在 process list 中出現，其文法如下：
SELECT t1.pid, t2.userid, t3.count, t1.date
FROM _mydata AS t1
LEFT JOIN _myuser AS t3 ON t1.userid=t3.userid
LEFT JOIN _mydata_body AS t2 ON t1.pid=t3.pid
ORDER BY t1.pid
LIMIT 0, 15

　　調用 show columns 檢查這三個表的結構：
MySQL> show columns from _myuser;
MySQL> show columns from _mydata;
MySQL> show columns from _mydata_body;

　　終於發現了問題所在：_mydata 表，只根據 pid 建立了一個 primary key，但並沒有為 userid 建立索引。而在這個
SQL 陳述式的第一個 LEFT JOIN ON 子句中：
LEFT JOIN _myuser AS t3 ON t1.userid=t3.userid

　　_mydata 的 userid 被參與了條件比較運算。於是我為給 _mydata 表根據欄位 userid 建立了一個索引：
MySQL> ALTER TABLE `_mydata` ADD INDEX ( `userid` )

　　建立此索引之後，CPU 馬上降到了 80% 左右。看到找到了問題所在，於是檢查另一個反覆出現在 show processlist 中的
sql 語句：
SELECT COUNT(*)
FROM _mydata AS t1, _mydata_key AS t2
WHERE t1.pid=t2.pid and t2.keywords = '孔雀'

　　經檢查_mydata_key 表的結構，發現它只為 pid 建了了 primary key，沒有為 keywords 建立
index。_mydata_key 目前有 33 萬條記錄，在沒有索引的情況下對33萬條記錄進行文本檢索匹配，不耗費大量的 CPU
時間才怪。看來就是針對這個表的檢索出問題了。於是同樣為 _mydata_key 表根據欄位 keywords 加上索引:
MySQL> ALTER TABLE `_mydata_key` ADD INDEX ( `keywords` )

　　建立此索引之後，CPU立刻降了下來，在 50%~70% 之間震蕩。

　　再次調用 show prosslist，網站 A 的 sql 調用就很少出現在結果清單中了。但發現此主機運行了幾個 Discuz
的論壇程式， Discuz 論壇的好幾個表也存在著這個問題。於是順手一併解決，CPU 佔用再次降下來了。

　　至此，問題解決。

　　解決 MySQL CPU 佔用 100% 的經驗總結

　　1. 增加 tmp_table_size 值。MySQL 的設定檔中，tmp_table_size 的預設大小是
32M。如果一張暫存資料表超出該大小，MySQL 產生一個 The table tbl_name is full 形式的錯誤，如果你做很多進階
GROUP BY 查詢，增加 tmp_table_size 值。 這是 MySQL 官方關於此選項的解釋：

　　tmp_table_size
　　This variable determines the maximum size for a temporary table in
memory. If the table becomes too large, a MYISAM table is created on
disk. Try to avoid temporary tables by optimizing the queries where
possible, but where this is not possible,
try to ensure temporary tables are always stored in memory. Watching the
processlist for queries with temporary tables that take too long to
resolve can give you an early warning that tmp_table_size needs to be
upped. Be aware that memory is also allocated per-thread.
An example where upping this worked for more was a server where I upped
this from 32MB (the default) to 64MB with immediate effect. The quicker
resolution of queries resulted in less threads being active at any one
time, with all-round benefits for the server, and available memory.

　　2. 對 WHERE、JOIN、MAX()、MIN()及ORDER BY 等子句中的條件判斷中用到的欄位，應該根據其建立索引 INDEX。

　　索引被用來快速找出在一個列上用一特定值的行。沒有索引，MySQL
不得不首先以第一條記錄開始並然後讀完整個表直到它找出相關的行。表越大，花費時間越多。如果表對於查詢的列有一個索引，MySQL
能快速到達一個位置去搜尋到資料檔案的中間，沒有必要考慮所有資料。如果一個表有 1000 行，這比順序讀取至少快 100
倍。所有的MySQL索引（PRIMARY、UNIQUE 及 INDEX）在B樹中儲存。

　　根據 MySQL 的開發文檔:

　　索引 index 用於：

　　o 快速找出匹配一個 WHERE 子句的行。

　　o 當執行連接 (JOIN) 時，從其他表檢索行。

　　o 對特定的索引列找出 MAX() 或 MIN() 值。

　　o 如果排序或分組在一個可用鍵的最左面首碼上進行（例如：ORDER BY key_part_1,
key_part_2），排序或分組一個表。如果所有索引值部分跟隨 DESC，鍵以倒序被讀取。

　　o
在一些情況中，一個查詢能被最佳化來檢索值，不用諮詢資料檔案。如果對某些表的所有使用的列是數字型的並且構成某些鍵的最左面首碼，為了更快，值可以從索引
樹被檢索出來。

　　假定你發出下列 SELECT 語句：
MySQL> SELECT * FROM tbl_name WHERE col1=val1 AND col2=val2;

　　如果一個多列索引存在於 col1 和 col2 上，適當的行可以直接被取出。如果分開的單行列索引存在於 col1 和 col2
上，最佳化器試圖通過決定哪個索引將找到更少的行並來找出更具限制性的索引並且使用該索引取行。

　　開發人員做 SQL 資料表設計的時候，一定要通盤考慮清楚。