场景和现象说明：
并发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排序问题）。
