《MYSQL教程MySQL服務(wù)器進(jìn)程CPU占用100%的解決方法》要點(diǎn):
本文介紹了MYSQL教程MySQL服務(wù)器進(jìn)程CPU占用100%的解決方法,希望對(duì)您有用。如果有疑問,可以聯(lián)系我們。
于是在服務(wù)器上運(yùn)行命令,將 mysql 當(dāng)前的環(huán)境變量輸出到文件 output.txt:MYSQL應(yīng)用
d:\web\mysql> mysqld.exe --help >output.txt
發(fā)現(xiàn) tmp_table_size 的值是默認(rèn)的 32M,于是修改 My.ini, 將 tmp_table_size 賦值到 200M:MYSQL應(yīng)用
d:\web\mysql> notepad c:\windows\my.ini [mysqld] tmp_table_size=200M
然后重啟 MySQL 服務(wù).CPU 占用有輕微下降,以前的CPU 占用波形圖是 100% 一根直線,現(xiàn)在則在 97%~100%之間起伏.這表明調(diào)整 tmp_table_size 參數(shù)對(duì) MYSQL 性能提升有改善作用.但問題還沒有完全解決.MYSQL應(yīng)用
于是進(jìn)入 mysql 的 shell 命令行,調(diào)用 show processlist, 查看當(dāng)前 mysql 使用頻繁的 sql 語句:MYSQL應(yīng)用
mysql> show processlist;
反復(fù)調(diào)用此命令,發(fā)現(xiàn)網(wǎng)站 A 的兩個(gè) SQL 語句經(jīng)常在 process list 中出現(xiàn),其語法如下:MYSQL應(yīng)用
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
調(diào)用 show columns 檢查這三個(gè)表的結(jié)構(gòu) :MYSQL應(yīng)用
mysql> show columns from _myuser; mysql> show columns from _mydata; mysql> show columns from _mydata_body;
終于發(fā)現(xiàn)了問題所在:_mydata 表,只根據(jù) pid 建立了一個(gè) primary key,但并沒有為 userid 建立索引.而在這個(gè) SQL 語句的第一個(gè) LEFT JOIN ON 子句中:MYSQL應(yīng)用
LEFT JOIN _myuser AS t3 ON t1.userid=t3.userid
_mydata 的 userid 被參與了條件比較運(yùn)算.于是我為給 _mydata 表根據(jù)字段 userid 建立了一個(gè)索引:MYSQL應(yīng)用
mysql> ALTER TABLE `_mydata` ADD INDEX ( `userid` )
建立此索引之后,CPU 馬上降到了 80% 左右.看到找到了問題所在,于是檢查另一個(gè)反復(fù)出現(xiàn)在 show processlist 中的 sql 語句:MYSQL應(yīng)用
SELECT COUNT(*) FROM _mydata AS t1, _mydata_key AS t2 WHERE t1.pid=t2.pid and t2.keywords = '孔雀'
經(jīng)檢查 _mydata_key 表的結(jié)構(gòu),發(fā)現(xiàn)它只為 pid 建了了 primary key, 沒有為 keywords 建立 index._mydata_key 目前有 33 萬條記錄,在沒有索引的情況下對(duì)33萬條記錄進(jìn)行文本檢索匹配,不耗費(fèi)大量的 cpu 時(shí)間才怪.看來就是針對(duì)這個(gè)表的檢索出問題了.于是同樣為 _mydata_key 表根據(jù)字段 keywords 加上索引:MYSQL應(yīng)用
mysql> ALTER TABLE `_mydata_key` ADD INDEX ( `keywords` )
建立此索引之后,CPU立刻降了下來,在 50%~70%之間震蕩.MYSQL應(yīng)用
再次調(diào)用 show prosslist,網(wǎng)站A 的sql 調(diào)用就很少出現(xiàn)在結(jié)果列表中了.但發(fā)現(xiàn)此主機(jī)運(yùn)行了幾個(gè) Discuz 的論壇程序, Discuz 論壇的好幾個(gè)表也存在著這個(gè)問題.于是順手一并解決,cpu占用再次降下來了.(2007.07.09 附注:關(guān)于 discuz 論壇的具體優(yōu)化過程,我后來另寫了一篇文章,詳見:千萬級(jí)記錄的 Discuz! 論壇導(dǎo)致 MySQL CPU 100% 的 優(yōu)化筆記 http://www.xiaohui.com/dev/server/20070701-discuz-mysql-cpu-100-optimize.htm)
解決 MYSQL CPU 占用 100% 的經(jīng)驗(yàn)總結(jié) MYSQL應(yīng)用
tmp_table_sizeMYSQL應(yīng)用
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應(yīng)用
根據(jù) mysql 的開發(fā)文檔: MYSQL應(yīng)用
索引 index 用于: MYSQL應(yīng)用
- 快速找出匹配一個(gè)WHERE子句的行
- 當(dāng)執(zhí)行聯(lián)結(jié)(JOIN)時(shí),從其他表檢索行.
- 對(duì)特定的索引列找出MAX()或MIN()值
- 如果排序或分組在一個(gè)可用鍵的最左面前綴上進(jìn)行(例如,ORDER BY key_part_1,key_part_2),排序或分組一個(gè)表.如果所有鍵值部分跟隨DESC,鍵以倒序被讀取.
- 在一些情況中,一個(gè)查詢能被優(yōu)化來檢索值,不用咨詢數(shù)據(jù)文件.如果對(duì)某些表的所有使用的列是數(shù)字型的并且構(gòu)成某些鍵的最左面前綴,為了更快,值可以從索引樹被檢索出來.
假定你發(fā)出下列SELECT語句:mysql> SELECT * FROM tbl_name WHERE col1=val1 AND col2=val2;如果一個(gè)多列索引存在于col1和col2上,適當(dāng)?shù)男锌梢灾苯颖蝗〕?如果分開的單行列索引存在于col1和col2上,優(yōu)化器試圖通過決定哪個(gè)索引將找到更少的行并來找出更具限制性的索引并且使用該索引取行.
開發(fā)人員做 SQL 數(shù)據(jù)表設(shè)計(jì)的時(shí)候,一定要通盤考慮清楚. MYSQL應(yīng)用
轉(zhuǎn)載請(qǐng)注明本頁網(wǎng)址:
http://www.fzlkiss.com/jiaocheng/1270.html