MySQL辦事器過程CPU占用100%的處理辦法。本站提示廣大學習愛好者：（MySQL辦事器過程CPU占用100%的處理辦法）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL辦事器過程CPU占用100%的處理辦法正文
因而在辦事器上運轉敕令，將 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 的服裝論壇t.vhao.net法式， Discuz 服裝論壇t.vhao.net的好幾個表也存在著這個成績。因而隨手一並處理，cpu占用再次降上去了。(2007.07.09 附注：關於 discuz 服裝論壇t.vhao.net的詳細優化進程，我後來另寫了一篇文章，詳見：萬萬級記載的 Discuz! 服裝論壇t.vhao.net招致 MySQL CPU 100% 的 優化筆記 http://www.xiaohui.com/dev/server/20070701-discuz-mysql-cpu-100-optimize.htm)
處理 MYSQL CPU 占用 100% 的經歷總結
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.
依據 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 數據表設計的時刻，必定要全盤斟酌清晰。
