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%，如下图：
4.1 前端页面响应超时：
4.2 数据库服务器资源使用率
4.3 LR响应时间指标分析
4.4 MYSQL 语法分析
在监控过程中发现若干SQL语法都是走全表扫描方式，导致响应时间和CPU使用率偏高，其中一个SQL如下
4.6、 优化方法
这时对表的需要检索字段建立索引后各项性能指标如下图
这时 同样是100用户并发，如下图建立索引前后响应时间走势图：
SQL 检索数据路径：
发现虽然建立索引，响应时间降低到2秒以下，但是数据库服务器cpu资源使用率仍然70%以上，偏高，这时发现缓存命中率不高，针对query_cache适当调整大小后，mysql数据库cpu使用率讲到30%以下和响应时间1秒以下，如下图。
响应时间指标如下：
原文地址：http://blog.51cto.com/372550/2089965