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-ntexe) CPU 占用率总为 100% 高居不下。此主机有10个左右的 database, 分别给十个网站调用。据朋友测试，导致 mysqld-ntexe cpu 占用奇高的是网站A，一旦在 IIS 中将此网站停止服务，CPU 占用就降下来了。一启用，则马上上升。

MYSQL CPU 占用 100% 的解决过程

今天早上仔细检查了一下。目前此网站的七日平均日 IP 为2000，PageView 为 3万左右。网站A 用的 database 目前有39个表，记录数 601万条，占空间 45MB。按这个数据，MySQL 不可能占用这么高的资源。

于是在服务器上运行命令，将 mysql 当前的环境变量输出到文件 outputtxt：

d:\web\mysql> mysqldexe --help >outputtxt

发现 tmp_table_size 的值是默认的 32M，于是修改 Myini, 将 tmp_table_size 赋值到 200M:

d:\web\mysql> notepad c:\windows\myini

[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 t1pid, t2userid, t3count, t1date

FROM _mydata AS t1

LEFT JOIN _myuser AS t3 ON t1userid=t3userid

LEFT JOIN _mydata_body AS t2 ON t1pid=t3pid

ORDER BY t1pid

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 t1userid=t3userid

_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 t1pid=t2pid and t2keywords = '孔雀'

经检查 _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占用再次降下来了。(20070709 附注：关于 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上，优化器试图通过决定哪个索引将找到更少的行并来找出更具限制性的索引并且使用该索引取行。

一个数据库服务器高iowait的优化案例

1开发反馈某一测试环境sql运行缓慢，而在其他测试环境该sql运行很快。两个环境其配置相同，均只部署了mysql服务器。

2执行top命令发现sql运行缓慢的机器上磁盘iowait较sql运行较快的机器高出很多。推测这是导致sql运行缓慢的主因，因为该sql是要读取表，表较大，且要扫描的行数较多。

3到底是什么导致机器iowait高呢，执行iotop发现消耗io的进程主要是mysql，而且主要是mysql上的读操作。

4想必是有其他高频运行的查询语句不停从某大表中查询数据，且查询时可能使用不到索引，要扫描的表行数较多，从而导致高频io操作，致使其他需io操作的sql运行缓慢。

5究竟是什么sql引起的呢？开启了general log，发现收集到的语句太多，且不能很好定位到高开销的sql。

6开启slow log,long_query_time置为1，来捕获慢查询，同时使用pt-ioprofile用来追踪mysql数据文件中哪些文件上的io消耗比较多。

7综合slow log(可使用pt-query-digest进行聚合)和pt-ioprofile的结果发现确实是两条典型的需要扫描全表的且对应的表非常大的sql频繁执行导致了磁盘的高io。

8那么剩下的问题便是优化表或者查询了。最简单直接的是通过建合适的索引来提升查询性能，减少表扫描行数，需要继续榨取性能的话就是优化sql的写法，调整表结构，调整参数配置来解决了。

9先从收益最大的方法入手，先评估sql语句，根据语句中的条件查看各个字段的数据分布情况，通过explain等评估在字段上创建索引或多列联合索引的合理性，并创建合适的索引。

10最后发现建好索引后原来需要扫全表的语句通过索引可有效减少扫描行数，继而io操作减少了，服务器的iowait讲题，原来反馈的运行较慢的sql运行速度得以提升，但还是不够理想。

11最后通过在该慢语句对应的表建索引，并修正where条件中使用错误的值类型极大的提升了sql语句运行速度，且服务器整体IO消耗大大降低。

12可通过pt-query-digest聚合优化后mysql server产生的slow log以及使用pt-ioprofile分析优化后mysql数据文件io占用情况，可了解到优化前后的差异情况。

数据库优化一方面是找出系统的瓶颈,提高MySQL数据库的整体性能,而另一方面需要合理的结构设计和参数调整,以提高用户的相应速度,同时还要尽可能的节约系统资源,以便让系统提供更大的负荷

1 优化一览图

2 优化

笔者将优化分为了两大类,软优化和硬优化,软优化一般是操作数据库即可,而硬优化则是操作服务器硬件及参数设置

21 软优化

211 查询语句优化

1首先我们可以用EXPLAIN或DESCRIBE(简写:DESC)命令分析一条查询语句的执行信息

2例:

显示:

其中会显示索引和查询数据读取数据条数等信息

212 优化子查询

在MySQL中,尽量使用JOIN来代替子查询因为子查询需要嵌套查询,嵌套查询时会建立一张临时表,临时表的建立和删除都会有较大的系统开销,而连接查询不会创建临时表,因此效率比嵌套子查询高

213 使用索引

索引是提高数据库查询速度最重要的方法之一,关于索引可以参高笔者<MySQL数据库索引>一文,介绍比较详细,此处记录使用索引的三大注意事项:

214 分解表

对于字段较多的表,如果某些字段使用频率较低,此时应当,将其分离出来从而形成新的表,

215 中间表

对于将大量连接查询的表可以创建中间表,从而减少在查询时造成的连接耗时

216 增加冗余字段

类似于创建中间表,增加冗余也是为了减少连接查询

217 分析表,,检查表,优化表

分析表主要是分析表中关键字的分布,检查表主要是检查表中是否存在错误,优化表主要是消除删除或更新造成的表空间浪费

1 分析表: 使用 ANALYZE 关键字,如ANALYZE TABLE user;

2 检查表: 使用 CHECK关键字,如CHECK TABLE user [option]

option 只对MyISAM有效,共五个参数值:

3 优化表:使用OPTIMIZE关键字,如OPTIMIZE [LOCAL|NO_WRITE_TO_BINLOG] TABLE user;

LOCAL|NO_WRITE_TO_BINLOG都是表示不写入日志,优化表只对VARCHAR,BLOB和TEXT有效,通过OPTIMIZE TABLE语句可以消除文件碎片,在执行过程中会加上只读锁

22 硬优化

221 硬件三件套

1配置多核心和频率高的cpu,多核心可以执行多个线程

2配置大内存,提高内存,即可提高缓存区容量,因此能减少磁盘I/O时间,从而提高响应速度

3配置高速磁盘或合理分布磁盘:高速磁盘提高I/O,分布磁盘能提高并行操作的能力

222 优化数据库参数

优化数据库参数可以提高资源利用率,从而提高MySQL服务器性能MySQL服务的配置参数都在mycnf或myini,下面列出性能影响较大的几个参数

223 分库分表

因为数据库压力过大，首先一个问题就是高峰期系统性能可能会降低，因为数据库负载过高对性能会有影响。另外一个，压力过大把你的数据库给搞挂了怎么办？所以此时你必须得对系统做分库分表 + 读写分离，也就是把一个库拆分为多个库，部署在多个数据库服务上，这时作为主库承载写入请求。然后每个主库都挂载至少一个从库，由从库来承载读请求。

224 缓存集群

如果用户量越来越大，此时你可以不停的加机器，比如说系统层面不停加机器，就可以承载更高的并发请求。然后数据库层面如果写入并发越来越高，就扩容加数据库服务器，通过分库分表是可以支持扩容机器的，如果数据库层面的读并发越来越高，就扩容加更多的从库。但是这里有一个很大的问题：数据库其实本身不是用来承载高并发请求的，所以通常来说，数据库单机每秒承载的并发就在几千的数量级，而且数据库使用的机器都是比较高配置，比较昂贵的机器，成本很高。如果你就是简单的不停的加机器，其实是不对的。所以在高并发架构里通常都有缓存这个环节，缓存系统的设计就是为了承载高并发而生。所以单机承载的并发量都在每秒几万，甚至每秒数十万，对高并发的承载能力比数据库系统要高出一到两个数量级。所以你完全可以根据系统的业务特性，对那种写少读多的请求，引入缓存集群。具体来说，就是在写数据库的时候同时写一份数据到缓存集群里，然后用缓存集群来承载大部分的读请求。这样的话，通过缓存集群，就可以用更少的机器资源承载更高的并发。

一个完整而复杂的高并发系统架构中，一定会包含：各种复杂的自研基础架构系统。各种精妙的架构设计因此一篇小文顶多具有抛砖引玉的效果,但是数据库优化的思想差不多就这些了

增加线程缓存大小

连接管理器线程处理服务器监听的网络接口上的客户端连接请求。连接管理器线程将每个客户端连接与专用于它的线程关联，该线程负责处理该连接的身份验证和所有请求处理。因此，线程和当前连接的客户端之间是一对一的比例。确保线程缓存足够大以容纳所有传入请求是非常重要的。

MySQL提供了许多与连接线程相关的服务器变量：

线程缓存大小由thread_cache_size系统变量决定。默认值为0（无缓存），这将导致为每个新连接设置一个线程，并在连接终止时需要处理该线程。如果希望服务器每秒接收数百个连接请求，那么应该将thread_cache_size设置的足够高，以便大多数新连接可以使用缓存线程。可以在服务器启动或运行时设置max_connections的值。

还应该监视缓存中的线程数（Threads_cached）以及创建了多少个线程，因为无法从缓存中获取线程（Threads_created）。关于后者，如果Threads_created继续以每分钟多于几个线程的增加，请考虑增加thread_cache_size的值。

使用MySQL show status命令显示MySQL的变量和状态信息。这里有几个例子：

Monyog线程缓存监测

Monyog提供了一个监控线程缓存的屏幕，名为“线程”。与MySQL线程相关的服务器变量映射到以下Monyog指标：

Monyog线程屏幕还包括“线程缓存命中率”指标。这是一个提示线程缓存命中率的指标。如果值较低，则应该考虑增加线程缓存。在状态栏以百分比形式显示该值；它的值越接近100％越好。

如果这些指标的值等于或超过指定值，则可以将每一个指标配置为发出警告和/或严重警报

1当我们请求mysql服务器的时候,MySQL前端会有一个监听,请求到了之后,服务器得到相关的SQL语句,执行之前(虚线部分为执行),还会做权限的判断

2通过权限之后,SQL就到MySQL内部,他会在查询缓存中,看该SQL有没有执行过,如果有查询过,则把缓存结果返回,说明在MySQL内部,也有一个查询缓存但是这个查询缓存,默认是不开启的,这个查询缓存,和我们的Hibernate，Mybatis的查询缓存是一样的,因为查询缓存要求SQL和参数都要一样,所以这个命中率是非常低的（没什么卵用的意思）。

3如果我们没有开启查询缓存,或者缓存中没有找到对应的结果,那么就到了解析器,解析器主要对SQL语法进行解析

4解析结束后就变成一颗解析树,这个解析树其实在Hibernate里面也是有的,大家回忆一下,在以前做过Hibernate项目的时候,是不是有个一个antlrjar。这个就是专门做语法解析的工具因为在Hibernate里面有HQL，它就是通过这个工具转换成SQL的,我们编程语言之所以有很多规范、语法,其实就是为了便于这个解析器解析,这个学过编译原理的应该知道

5得到解析树之后,不能马上执行,这还需要对这棵树进行预处理,也就是说,这棵树,我没有经过任何优化的树,预处理器会这这棵树进行一些预处理,比如常量放在什么地方,如果有计算的东西,把计算的结果算出来等等

6预处理完毕之后,此时得到一棵比较规范的树,这棵树就是要拿去马上做执行的树,比起之前的那棵树,这棵得到了一些优化

7查询优化器，是MySQL里面最关键的东西,我们写任何一条SQL,比如SELECT FROM USER WHERE USERNAME = toby AND PASSWORD = 1,它会怎么去执行它是先执行username = toby还是password = 1每一条SQL的执行顺序查询优化器就是根据MySQL对数据统计表的一些信息,比如索引,比如表一共有多少数据,MySQL都是有缓存起来的,在真正执行SQL之前,他会根据自己的这些数据,进行一个综合的判定,判断这一次在多种执行方式里面,到底选哪一种执行方式,可能运行的最快这一步是MySQL性能中,最关键的核心点,也是我们的优化原则我们平时所讲的优化SQL,其实说白了,就是想让查询优化器,按照我们的想法,帮我们选择最优的执行方案,因为我们比MySQL更懂我们的数据MySQL看数据,仅仅只是自己收集到的信息,这些信息可能是不准确的,MySQL根据这些信息选了一个它自认为最优的方案,但是这个方案可能和我们想象的不一样

8这里的查询执行计划,也就是MySQL查询中的执行计划,比如要先执行username = toby还是password = 1

9这个执行计划会传给查询执行引擎,执行引擎选择存储引擎来执行这一份传过来的计划,到磁盘中的文件中去查询,这个时候重点来了,影响这个查询性能最根本的原因是什么就是硬盘的机械运动,也就是我们平时熟悉的IO,所以一条查询语句是快还是慢,就是根据这个时间的IO来确定的那怎么执行IO又是什么来确定的就是传过来的这一份执行计划(优化就是制定一个我们认为最快的执行方案,最节省IO,和执行最快)

10如果开了查询缓存,则返回结果给客户端,并且查询缓存也放一份。