Mysql CPU佔用高的問題解決方法小結

最近發現php網站發佈信息比較慢，並且同網站目錄下的asp常常登陸後當即就從新登陸，當即考慮到服務器資源佔用問題，因此進服務器看到原來mysql佔用率較高 25-60%左右，偶爾能跑到100%，全部致使上述問題的發生,根據以前的mysql配置，先將mysql的配置問題排除了，查看msyql是否運行正常，經過查看mysql data目錄裏面的*.err文件(將擴展名改成.txt)記事本查看便可。若是過大不建議用記事本了，容易死掉，能夠用editplus等工具

簡單的分爲下面幾個步驟來解決這個問題：

一、mysql運行正常，也有多是同步設置問題致使

二、若是mysql運行正常，那就是php的一些sql語句致使問題發現，用root用戶進入mysql管理
mysql -u root -p
輸入密碼
mysql:show processlist 語句，查找負荷最重的 SQL 語句，優化該SQL，好比適當創建某字段的索引。

經過這個命令我看到原來是有人惡意刷搜索，由於dedecms搜索後面調用搜索最高的詞，致使不少人用工具刷這個，並且是定時有間隔的，因此將這個php程序更名跳轉都方法解決了。

固然若是你的確實是sql語句用了大量的group by等語句，union聯合查詢等確定會將mysql的佔用率提升。因此就須要優化sql語句，網站儘可能生成靜態的，通常4W ip的靜態網站，mysql佔用率幾乎爲0的。因此這對於程序員的經驗是個考慮。儘可能提升mysql性能 (MySQL 性能優化的最佳20多條經驗分享)

下面是腳本之家收集的文章，你們均可以參考下

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佔用再次降下來了。(2007.07.09 附註：關於 discuz 論壇的具體優化過程，我後來另寫了一篇文章，詳見：千萬級記錄的 Discuz! 論壇致使 MySQL CPU 100% 的 優化筆記 http://www.xiaohui.com/dev/server/20070701-discuz-mysql-cpu-100-optimize.htm)

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

增長 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.

對 WHERE, JOIN, MAX(), MIN(), ORDER BY 等子句中的條件判斷中用到的字段,應該根據其創建索引 INDEX。索引被用來快速找出在一個列上用一特定值的行。沒有索引，MySQL不得不首先以第一條記錄開始並而後讀完整個表直到它找出相關的行。表越大，花費時間越多。若是表對於查詢的列有一個索引，MySQL能快速到達一個位置去搜尋到數據文件的中間，沒有必要考慮全部數據。若是一個表有1000行，這比順序讀取至少快100倍。全部的MySQL索引(PRIMARY、UNIQUE和INDEX)在B樹中存儲。

根據 mysql 的開發文檔:

索引 index 用於：

快速找出匹配一個WHERE子句的行
當執行聯結(JOIN)時，從其餘表檢索行。
對特定的索引列找出MAX()或MIN()值
若是排序或分組在一個可用鍵的最左面前綴上進行(例如，ORDER BY key_part_1,key_part_2)，排序或分組一個表。若是全部鍵值部分跟隨DESC，鍵以倒序被讀取。

在一些狀況中，一個查詢能被優化來檢索值，不用諮詢數據文件。若是對某些表的全部使用的列是數字型的而且構成某些鍵的最左面前綴，爲了更快，值能夠從索引樹被檢索出來。

假定你發出下列SELECT語句：

mysql> SELECT * FROM tbl_name WHERE col1=val1 AND col2=val2; 若是一個多列索引存在於col1和col2上，適當的行能夠直接被取出。若是分開的單行列索引存在於col1和col2上，優化器試圖經過決定哪一個索引將找到更少的行並來找出更具限制性的索引而且使用該索引取行。