mysql负载时高时低_mysql负载飙高原因分析

某些进程/服务消耗更多CPU资源(服务响应更多请求或存在某些应用瓶颈)；

发生比较严重的swap(可用物理内存不足)；

发生比较严重的中断(因为SSD或网络的原因发生中断)；

磁盘I/O比较慢(会导致CPU一直等待磁盘I/O请求)；

绝对不要因表数据量小，sql语句随便写都行，随便join都不会出现性能瓶颈，决不能有这

种思想。

尽量避免join表 join表笛卡尔积

如果要join表一定要把where条件写全，安全起见最好加个limit。

一次请求读写的数据量太大，导致磁盘I/O读写值较大，例如一个SQL里要读取或更新几万>行数据甚至更多，这种最好是想办法减少一次读写的数据量；

SQL查询中没有适当的索引可以用来完成条件过滤、排序(ORDER BY)、分组(GROUP BY)

、数据聚合(MIN/MAX/COUNT/AVG等)，添加索引或者进行SQL改写吧；

瞬间突发有大量请求，这种一般只要能扛过峰值就好，保险起见还是要适当提高服务器的>配置，万一峰值抗不过去就可能发生雪崩效应；

因为某些定时任务引起的负载升高，比如做数据统计分析和备份，这种对CPU、内存、磁盘

I/O消耗都很大，最好放在独立的slave服务器上执行；

服务器自身的节能策略发现负载较低时会让CPU降频，当发现负载升高时再自动升频，但通

常不是那么及时，结果导致CPU性能不足，抗不过突发的请求；

使用raid卡的时候，通常配备BBU(cache模块的备用电池)，早期一般采用锂电池技术，>需要定期充放电(DELL服务器90天一次，IBM是30天)，我们可以通过监控在下一次充放电

的时间前在业务低谷时提前对其进行放电，不过新一代服务器大多采用电容式电池，也就>不存在这个问题了。

文件系统采用ext4甚至ext3，而不是xfs，在高I/O压力时，很可能导致%util已经跑到100%了，但iops却无法再提升，换成xfs一般可获得大幅提升；

内核的io scheduler策略采用cfq而非deadline或noop，可以在线直接调整，也可获得大幅

提升。