阿里雲mysql性能,阿里雲mysql性能

本文目錄一覽：

• 1、mysqld佔用CPU過高是什麼原因
• 2、MySQL CPU佔用過高怎麼辦
• 3、Mysql佔用CPU過高如何優化
• 4、阿里雲cpu檢測進程mysql太高怎麼解決
• 5、mysql 伺服器CPU佔用過高，如何調優，求助
• 6、阿里雲伺服器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 CPU佔用過高原因主要有以下幾種

CPU過時（比較舊的CPU）

RAM資源不足（RAM記憶體）

解決辦法如下：

①臨時解決方案

首先是ctrl+alt+delete快捷鍵打開工作管理員

然後找到下方圖一中的mysqld.exe

右擊移至詳細資料

再來右擊設定優先順序

按照下方圖二的步驟

根據佔用情況調整成低於標準或者低

這個方法只能臨時解決

②實際解決方法是更換CPU

總結：根據正常的mysql使用，即使大量數據往來也不會造成CPU佔用過高，目前推論應該是CPU比較過時的原因，治標不治本的臨時解決方案。

備註：如採取方案②你需要備份你的資料，因為更換CPU會有很大的機會需要重新安裝你的作業系統。

Mysql佔用CPU過高如何優化

CPU佔用過高診斷思路

mpstat -P ALL 1，查看cpu使用情況，主要消耗在sys即os系統調用上

perf top，cpu主要消耗在_spin_lock

生成perf report查看詳細情況

CPU主要消耗在mutex爭用上，說明有鎖熱點。

採用pt-pmp跟蹤mysqld執行情況，熱點主要集中在mem_heap_alloc和mem_heap_free上。

Pstack提供更詳細的API調用棧

Innodb在讀取數據記錄時的API路徑為

row_search_for_mysql –》row_vers_build_for_consistent_read –》mem_heap_create_block_func –》mem_area_alloc –》malloc –》  _L_unlock_10151 –》__lll_unlock_wait_private

row_vers_build_for_consistent_read會陷入一個死循環，跳出條件是該條記錄不需要快照讀或者已經從undo中找出對應的快照版本，每次循環都會調用mem_heap_alloc/free。

而該表的記錄更改很頻繁，導致其undo history list比較長，搜索快照版本的代價更大，就會頻繁的申請和釋放堆內存。

Linux原生的內存庫函數為ptmalloc，malloc/free調用過多時很容易產生鎖熱點。

當多條 SQL 並發執行時，會最終觸發os層面的spinlock，導致上述情形。

解決方案

將mysqld的內存庫函數替換成tcmalloc，相比ptmalloc，tcmalloc可以更好的支持高並發調用。

修改my.cnf，添加如下參數並重啟

[mysqld_safe]malloc-lib=tcmalloc

上周五早上7點執行的操作，到現在超過72小時，期間該實例沒有再出現cpu長期飆高的情形。

以下是修改前後cpu使用率對比

阿里雲cpu檢測進程mysql太高怎麼解決

一台伺服器解決了 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.dateFROM _mydata AS t1

LEFT JOIN _myuser AS t3 ON t1.userid=t3.useridLEFT JOIN _mydata_body AS t2 ON t1.pid=t3.pidORDER 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 值。 這是 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上，優化器試圖通過決定哪個索引將找到更少的行並來找出更具限制性的索引並且使用該索引取行。

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

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

阿里雲伺服器CPU 跑滿怎麼辦

應該是你網站被攻擊了，如DDOS/CC攻擊這些都是消耗你伺服器資源的。解決辦法是購買阿里雲高防IP，防火牆。不過阿里雲的價格貴死。推薦你用百度雲加速的吧。

百度雲加速是百度旗下為網站提供一站式加速、安全防護和搜索引擎優化的產品。百度雲加速是市場佔有率最高的雲加速產品之一，正為數十萬用戶的近百萬網站提供CDN、網路安全和SEO服務。每天處理十億級的PV流量及數百億TB的數據流量，並提供市場頂尖水平的穩定性和抗攻擊能力。

百度雲加速以部署於骨幹網的數據中心為支撐，結合百度深度學習技術，為您的網站提供性能和流量優化，致力與廣大開發者一起於打造開放、安全的雲服務生態系統。 我們希望更多的網站合作夥伴以及中小企業能受益於百度雲加速帶來的價值及紅利，從而使得雲生態能夠更加良性的發展。

百度雲加速為用戶提下以下三大類功能：

1、網站加速

百度雲加速節點遍布全中國，通過智能DNS解析等技術，將訪問網站的用戶引導至最快的節點，通過動靜態加速及頁面優化技術，極大的提高網站的訪問速度和用戶體驗。此外，還可以大量節省網站自身的服務計算和帶寬資源。

2、安全防護

百度雲加速可以同時防護包括SQL注入、XSS、Web伺服器漏洞、應用程序漏洞以及文件訪問控制等問題在內的十多種黑客滲透攻擊和SYN Flood、UDP Flood、ICMP Flood、TCP Flood以及CC在內的多種DDoS攻擊。

3、SEO

百度雲加速的百度蜘蛛DNS同步功能，可以做到和百度蜘蛛實時同步DNS信息，保證百度蜘蛛的正常抓取，保證搜索引擎權重的穩定性；通過死鏈自動提交、sitemap自動提交，及時收錄網站信息，提高網站索引量。