Mysql数据库CPU使用率异常排查

 概述：

        为保障双十一活动期间基础组件服务的稳定型，我们做了一波压测来确定我们基础服务的吞吐能力，发现当我们开放api 达到2500tps时，rt升高出现毛刺，数据库（MYSQL）cpu使用达到100%，然后做了一轮优化（api 请求事件投递到MQ 和 数据库升级，以及相关限流处理），重新压测确保5000tps运行正常（基础服务部署在8台ecs，如果在扩展集群增加MQ处理能力依然会造成数据库cpu100%），可以使基础服务平稳支撑业务方调用。2021-10-31开始持续观察RDS运行情况发现CPU使用率维持在45-55%区间，活跃线程数维持在15以内，基础服务运行平稳。在2021-11-7日之后观察发现CPU使用率突然降低维持在6-22%区间（这是个好的现象），活跃线程数在2-6以内，基础服务运行平稳。为什么mysql cpu使用率会降低那么多呢？

 

通过阿里云查询七天内的相关监控图：

CPU和内存使用率：

 磁盘空间和IOPS：

注：IOPS虽然有一些比较高的峰值但是基本上运行是平稳的，直观上对CPU突然降低没什么参考价值

连接数：从图中可以直观的看出活跃连接数在2021-11-7日前维持在7-10之间，2021-11-7日后活跃连接数维持在1-5之间，由于基础服务业务逻辑没有变化（我们有个基础服务管理页面查看个各业务方调用记录的页面，此页面查询会比较慢）

推测：慢SQL查询过多导致数据库MYSQL CPU升高

        推测理由：基础服务运行逻辑没变，双十一期间大家使用管理平台频繁查询产生很多慢sql导致CPU飙升维持在45-56%，由于预售缓解了业务压力以及基础服务稳定后期相关人员减少管理平台使用CPU慢慢降低恢复正常

        验证：两个人同时登陆管理平台，通过模拟多次点击和扩大查询范围，验证慢sql会导致CPU升高

       验证期间线程数（活跃线程数）和 CPU使用率截图： 

活跃线程数：升高

 MYSQL CPU使用率：升高

初步结论：2021-11-7日前cpu使用率高是主要是由于慢sql过多导致，依据活跃线程数变化和cpu使用率变化一致，基础服务业务运行逻辑无变化。

由于我们使用的是云产品，因此有这些直观监测走势图，如果是IDC机房自己搭建的数据库（MYSQL）可以考虑安装相关第三方的监控中间件观察或者通过查询mysql 活跃线程数和慢sql查询来定位问题。

查询MYSQL中的活跃线程数参考SQL语句： 

SELECT * FROM information_schema.processlist where command='Query'

效果图：

解释：此条sql语句用于查询：当前时刻查询类型（select xxx from xxx）的活跃线程数，大家可以看看这张表有哪些数据以此来快速定位问题