性能测试实战分享4---mysql数据库进程的CPU使用率占用很高

场景和现象说明：

并发30个，响应时间不达标。

监控服务器，发现cpu使用率占用一直很高且接近100%，内存使用率基本保持不变；

 

问题：响应时间平均大于2秒，最高能达到4秒多，不达标（需求平均响应时间<500毫秒）；

 

监控现象：

1、服务器cpu使用率占用一直很高且接近100%；

2、服务器内存使用率基本保持不变；

3、响应时间平均大于2秒，最高能达到4秒多；

原因分析：

1、SQL语句存在大量的慢查询，导致mysql数据库进程CPU占用高；

2、再深究慢查询的SQL语句，发现使用全表查询未使用索引。

解决方案：使用索引替换全表查询方式；

分析思路：

分析客户端和服务端的性能，看是否有性能瓶颈（CPU，内存，磁盘，网络）--->CPU使用率占用一直很高且接近100%--->分析CPU占用过高的进程，发现是mysql数据库进程--->查询CPU占用高时使用的SQL语句，分析该SQL语句是不是存在慢查询问题--->最后分析SQL语句慢查询的原因（一般为使用全表查询方式，GroupBy、OrderBy排序问题）

本次测试的经验分享：

1、通过监控分析服务端的硬件性能，看是否有性能瓶颈（CPU，内存，磁盘，网络），结果：CPU使用率占用一直很高且接近100%现象，初步可定位是CPU问题。

 

2、分析CPU占用过高的进程，发现是MSQL数据库进程。

 

3、查询CPU占用高时使用的SQL语句，分析该SQL语句是不是存在慢查询问题。

（1）通过show variables like ‘slow_query_log%’来查看慢查询日志的路径。

 

（2）排查慢查询日志文件中的慢SQL语句

 

SELECT id FROM `WJJ_JOB_QRTZ_TRIGGER_LOG` WHERE !( (trigger_code in (0, 200) and handle_code = 0) OR (handle_code = 200) ) AND `alarm_status` = 0 ORDER BY id ASC;

4、最后分析SQL语句慢查询的原因。

使用expain命令，发现使用全表查询方式<ALL>（需使用索引）

 

5、性能优化。

（1）针对上面的SQL语句添加索引。

（2）如果添加了索引还是CPU占用过高，就需要优化SQL语句本身（可以考虑GroupBy、OrderBy排序问题）。