mysqld服務器cpu（mysqld_server）

本文目錄一覽：

• 1、Mysql數據庫CPU佔用過高原因排查 show processlist
• 2、服務器mysqld.exe進程，佔用CPU100%高居不下，請大神幫助！！！
• 3、mysql數據庫服務器CPU負載超過200%，mysqld進程導致的，如何解決？
• 4、mysqld佔用CPU過高是什麼原因
• 5、mysql 服務器CPU佔用過高，如何調優，求助

Mysql數據庫CPU佔用過高原因排查 show processlist

mysql服務器最近偶爾出現cpu百分百居高不下的情況，所以需要進行分析

兄弟命令 show processlist;只列出前100條，如果想全列出請使用show full processlist;

先 簡單說一下各列的含義和用途：

正在將表中修改的數據刷新到磁盤中，同時正在關閉已經用完的表。這是一個很快的操作，如果不是這樣的話，就應該確認磁盤空間是否已經滿了或者磁盤是否正處於重負中。

Connect Out

複製從服務器正在連接主服務器。

Copying to tmp table on disk

由於臨時結果集大於 tmp_table_size，正在將臨時表從內存存儲轉為磁盤存儲以此節省內存。

Creating tmp table

正在創建臨時表以存放部分查詢結果。

deleting from main table

服務器正在執行多表刪除中的第一部分，剛刪除第一個表。

deleting from reference tables

服務器正在執行多表刪除中的第二部分，正在刪除其他表的記錄。

Flushing tables

正在執行 FLUSH TABLES，等待其他線程關閉數據表。

Killed

發送了一個kill請求給某線程，那麼這個線程將會檢查kill標誌位，同時會放棄下一個kill請求。MySQL會在每次的主循環中檢查kill標誌 位，不過有些情況下該線程可能會過一小段才能死掉。如果該線程程被其他線程鎖住了，那麼kill請求會在鎖釋放時馬上生效。

Locked

被其他查詢鎖住了。

Sending data

正在處理 SELECT 查詢的記錄，同時正在把結果發送給客戶端。

Sorting for group

正在為 GROUP BY 做排序。

Sorting for order

正在為 ORDER BY 做排序。

Opening tables

這個過程應該會很快，除非受到其他因素的干擾。例如，在執 ALTER TABLE 或 LOCK TABLE 語句行完以前，數據表無法被其他線程打開。 正嘗試打開一個表。

Removing duplicates

正在執行一個 SELECT DISTINCT 方式的查詢，但是MySQL無法在前一個階段優化掉那些重複的記錄。因此，MySQL需要再次去掉重複的記錄，然後再把結果發送給客戶端。

Reopen table

獲得了對一個表的鎖，但是必須在表結構修改之後才能獲得這個鎖。已經釋放鎖，關閉數據表，正嘗試重新打開數據表。

Repair by sorting

修復指令正在排序以創建索引。

Repair with keycache

修復指令正在利用索引緩存一個一個地創建新索引。它會比 Repair by sorting 慢些。

Searching rows for update

正在講符合條件的記錄找出來以備更新。它必須在 UPDATE 要修改相關的記錄之前就完成了。

Sleeping

正在等待客戶端發送新請求.

System lock

正在等待取得一個外部的系統鎖。如果當前沒有運行多個 mysqld 服務器同時請求同一個表，那麼可以通過增加 –skip-external-locking參數來禁止外部系統鎖。

U pgrading lock

INSERT DELAYED 正在嘗試取得一個鎖表以插入新記錄。

Updating

正在搜索匹配的記錄，並且修改它們。

User Lock

正在等待 GET_LOCK()。

Waiting for tables

該線程得到通知，數據表結構已經被修改了，需要重新打開數據表以取得新的結構。然後，為了能的重新打開數據表，必須等到所有其他線程關閉這個表。以下幾種 情況下會產生這個通知：FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE, 或 OPTIMIZE TABLE。

waiting for handler insert

INSERT DELAYED 已經處理完了所有待處理的插入操作，正在等待新的請求。

大部分狀態對應很快的操作，只要有一個線程保持同一個狀態好幾秒鐘，那麼可能是有問題發生了，需要檢查一下。

還有其他的狀態沒在上面中列出來，不過它們大部分只是在查看服務器是否有存在錯誤是才用得着。

文章轉自：

服務器mysqld.exe進程，佔用CPU100%高居不下，請大神幫助！！！

是不是有個慢查詢在運行，用：

SHOW PROCESSLIST

顯示當前正在執行的程序或查詢

mysql數據庫服務器CPU負載超過200%，mysqld進程導致的，如何解決？

可以先使用 uptime 命令查看 CPU 平均負載

那個 2 users 表示用戶連接數，指的是總連接數。

那個 load average 就是系統平均負載，1 分鐘、5 分鐘、15 分鐘系統負載的平均值。

指的是一段時間內 CPU 正在處理以及等待 CPU 處理的進程數之和的統計信息，也就是 CPU 使用隊列的長度的統計信息。這個數字越小越好。

然後再用 vmstat 命令看下 CPU 是否飽和

這裡面的 r 就是等待 CPU 的進程數，可以用來判定 CPU 是否飽和，當 r 值高於 CPU 數時，就意味着飽和了。

最右邊那個 us，sy，id，wa，st 表示所有 CPU 的使用百分比。它們分別是 user time，system time，idle，wait I/O 和 steal time 的縮寫。將 us 和 sy 的百分比加和，可以確定 CPU 是否處於忙碌狀態。

如果是多核的機器還可以使用 mpstat 命令查看是否均衡

與 CPU 相關的命令還有 pidstat

這個命令展示了 CPU 消耗在了哪些進程上面，消耗過大的進程需要格外關注下。

基本上你使用上述幾個命令 就可以初步了解 CPU 出現了何種問題

有了猜測的方向之後 你就可以進一步深入去排查了

mysqld佔用CPU過高是什麼原因

一般是睡眠連接過多，嚴重消耗mysql服務器資源(主要是cpu, 內存)，並可能導致mysql崩潰。

解決辦法 ：

mysql的配置my.ini文件中，有一項：

wait_timeout, 即可設置睡眠連接超時秒數，如果某個連接超時，會被mysql自然終止。

wait_timeout過大有弊端，其體現就是MySQL里大量的SLEEP進程無法及時釋放，拖累系統性能，不過也不能把這個指設置的過小，否則你可能會遭遇到“MySQL has gone away”之類的問題，通常來說，我覺得把wait_timeout設置為10是個不錯的選擇，但某些情況下可能也會出問題，比如說有一個CRON腳本，其中兩次SQL查詢的間隔時間大於10秒的話，那麼這個設置就有問題了（當然，這也不是不能解決的問題，你可以在程序里時不時mysql_ping一下，以便服務器知道你還活着，重新計算wait_timeout時間）：

mysql show global variables like ‘wait_timeout’;

+—————————-+——-+

| Variable_name | Value |

+—————————-+——-+

| wait_timeout | 120 |

+—————————-+——-+

mysql set global wait_timeout=20;

至此，mysql佔用cpu下降了

mysql 服務器CPU佔用過高，如何調優，求助

通過以前對mysql的操作經驗，先將mysql的配置問題排除了，查看msyql是否運行正常，通過查看mysql data目錄裡面的*.err文件(將擴展名改為.txt)記事本查看即可。如果過大不建議用記事本了，容易死掉，可以用editplus等工具。

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

1、mysql運行正常，也有可能是同步設置問題導致

2、如果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% 的 優化筆記 )

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

增加 tmp_table_size 值。mysql 的配置文件中，tmp_table_size 的默認大小是 32M。如果一張臨時表超出該大小，MySQL產生一個 The table tbl_name is full 形式的錯誤，如果你做很多高級 GROUP BY 查詢，增加 tmp_table_size 值。

對 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上，優化器試圖通過決定哪個索引將找到更少的行並來找出更具限制性的索引並且使用該索引取行。