当前位置:七道奇文章资讯数据防范MySQL防范
日期:2012-06-05 16:11:00  来源:本站整理

Mysql CPU占用高的问题办理办法小结[MySQL防范]

赞助商链接



  本文“Mysql CPU占用高的问题办理办法小结[MySQL防范]”是由七道奇为您精心收集,来源于网络转载,文章版权归文章作者所有,本站不对其观点以及内容做任何评价,请读者自行判断,以下是其具体内容:
通过从前对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% 的 优化笔记 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上,优化器试图通过决意哪个索引将找到更少的行并来找出更具限制性的索引并且利用该索引取行.

  开辟人员做 SQL 数据表计划的时刻,一定要通盘考虑清楚
  以上是“Mysql CPU占用高的问题办理办法小结[MySQL防范]”的内容,如果你对以上该文章内容感兴趣,你可以看看七道奇为您推荐以下文章:
  • Windows 搭配 IIS7 PHP MySQL 环境
  • mysql Out of memory (Needed 16777224 bytes)的错误办理
  • mysql提醒[Warning] Invalid (old?) table or database name问题的办理办法
  • mysql启用skip-name-resolve情势时呈现Warning的处理办法
  • mysql启用skip-name-resolve情势时呈现Warning的处理办法
  • MySQL Order By语法介绍
  • <b>MySQL ORDER BY 的实现解析</b>
  • mysql数据库插入速度和读取速度的调整记录
  • MySQL Order By索引优化办法
  • MySQL Order By用法分享
  • mysql #1062 –Duplicate entry ''1'' for key ''PRIMARY''
  • MySQL Order By Rand()效率解析
  • 本文地址: 与您的QQ/BBS好友分享!
    • 好的评价 如果您觉得此文章好,就请您
        0%(0)
    • 差的评价 如果您觉得此文章差,就请您
        100%(1)

    文章评论评论内容只代表网友观点,与本站立场无关!

       评论摘要(共 0 条,得分 0 分,平均 0 分) 查看完整评论
    Copyright © 2020-2022 www.xiamiku.com. All Rights Reserved .