做性能测试做多了，你会发现服务器最慢的是 io，而数据库是经常和 io 打交道的，所以是最容易出现瓶颈和问题的就是数据库服务器，一不小心就会崩掉。在这里分享一个在实际性能项目中成功解决 cpu 高负荷问题。


更多测试技能干货，可以关注微信公众号<大话性能>

更多好文章

1、问题描述

某项目是在做性能测试的过程中，发现某个计数查询接口小并发的压测后，mysql 数据库服务器的 CPU（4 核）就满负荷运行，而接口的 tps 也是很小。

2、问题解决

根据经验，数据库的 cpu 满负荷运行，大部分情况下是索引没建好。

问题定位和解决步骤：

1、登陆 mysql 的服务器后，执行 mysql -uroot -proot -h192.168.16.59 -P33061 -e 'show full processlist;' | grep -v 'Sleep' ，观察有无执行缓慢或者经常出现的 sql 语句，发现不断出现 select count(*) from t_member_dayranklist WHERE ( update_date = '2015-11-02 00:00:00' and department_id = 22292800 );类似语句。

2、于是 explain 它们，观察 MySQL 是如何处理该 SQL 语句的，索引是如何被利用的，数据表是如何被搜索和排序的。

3、Show index from t_member_dayranklist 后发现建立的表索引只有列 update_date， department_id 的单独索引，而 explain 查询语句结果如下，发现需要搜索的 rows 也有 5506 行，并且显示索引被使用的 ref 值为 null，可见索引有优化的空间。

4、于是尝试 alter table t_member_dayranklist add index date_dept_idx (update_date , department_id);增加一个组合索引。

5、修改后发现索引的效率确实高了一些，而此时索引也确实是按照我添加的 date_dept_idx 进行搜索，搜索的行数也比之前的少了 2/3。

3、结果对比

优化后的效果出乎我的想象，第一次切身感受到了正确的索引带来的性能提升还是很客观的，具体结果如下：

从上图，可以清晰的看出 Mysql 数据库服务器的 CPU 平均使用率下降了接近了 55%，接口的平均响应时间从 1023ms 下降到 113ms，而 TPS 处理能力从 97.5/s 上升到 873.0/s，很好的满足了系统和接口的需求。

在实际 mysql 数据库性能调优中，十有八九的问题都可以从索引出发，不仅仅要建立相应的索引，还要建立合理的索引，最后还要测试索引是否生效。
更多性能测试相关学习可以关注公众号大话性能。更多好文章