MYSQL数据库服务CPU高问题分析与优化

MySQL服务性能监控分析与优化是永恒的主题，做为性能测试人员有时也要站在DBA角度出发进行适当分析与优化，这也是性能测试人员能长期生存发展存在意义。而资源的使用监控分析才是性能故障分析的根本首要任务。在数据库服务器内部，如果执行的操作会严重受到内存、CPU或磁盘吞吐量中任何一个的影响，则可以将它视为瓶颈。
因此理解服务器如何运行，资源损耗在哪些方面对问题进行故障诊断时非常有价值，具体案例如下。
1、 识别瓶颈
在分析性能问题时，首先需要识别瓶颈，然后将该瓶颈解决。产生瓶颈的原因通常有两类，一类是由于错误的配置，另一类是达到了软件或硬件的性能或可伸缩性的限制，例如SQL语法问题。
2、 识别CPU瓶颈
前面章节我们有讲到《MYSQL数据库服务磁盘IO高问题分析与优化》有提到IO 问题故障分析与解决方案，而本章主要是讲解CPU 问题定位分析与解决方案。
CPU时间开销是最昂贵、最宝贵的服务器资源，并且系统总体性能往往对CPU使用率非常敏感。例如，用户经常可以察觉到高CPU使用率的状况，就是响应时间慢，超时现象等。
3、 瓶颈根源分析
MYSQL自身经常会导致高CPU使用率的情形，包括执行差效率的查询、哈希连接或多表合并连接、参数设置不合理等。
4、 案例说明如下
测试场景，在压力测试某银行系统登录退出时，因用户登录需要查询对应的客户相关交易信息等，而需要涉及SQL查询，这时LR 并发100用户时，响应时间5秒多，人工登录发现出现超时错误信息，这时通过top命令监控到CPU使用率超过90%，如下图：
前端页面响应超时：

数据库服务器资源使用率

LR响应时间指标分析

MYSQL 语法分析
在监控过程中发现若干SQL语法都是走全表扫描方式，导致响应时间和CPU使用率偏高，其中一个SQL如下

5、 优化方法
这时对表的需要检索字段建立索引后各项性能指标如下图

这时 同样是100用户并发，如下图建立索引前后响应时间走势图

SQL 检索数据路径：

发现虽然建立索引，响应时间降低到2秒以下，但是数据库服务器cpu资源使用率仍然70%以上，偏高，这时发现缓存命中率不高，针对query_cache适当调整大小后，mysql数据库cpu使用率讲到30%以下和响应时间1秒以下，如下图。

响应时间指标如下：