1.背景：在监控线上数据库的运行是否安全、正常的过程中，cpu 使用率是一个重要的指标，一旦cpu使用率飙升至90%+甚至达到100%，必然会对数据库的正常工作产生影响
在排查数据库的cpu 飙升的问题前，我们先看下cpu 飙升的原因有哪些
2.cpu使用率飙升的原因首先直观的，cpu使用率过高可能和流量和慢查询有一定的关系进一步查阅相关资料，得到公式：单位时间 CPU 资源 = 查询执行的平均成本 x 单位时间执行的查询数量显然，cpu使用率与【查询执行的平均成本】和【单位时间执行的查询数量】线性相关，而这两项就是我们常说的慢sql以及数据库QPS
所以：一般而言，cpu使用率飙升可归纳为以下两点：大量的慢sql占用了cpu资源，拖垮了数据库，这类的慢sql常常表现为：查询的数据量过大，全表扫描、锁抢占甚至死锁、复杂查询等QPS过高，本质上是数据库的承载的流量过大3.如何解决3.1 定位问题定位是否为qps原因:例如以下案例：首先，查看当前cpu曲线：发现此时的cpu已经解决100%在运行，再查看此时的qps曲线，会发现此时的qps曲线基本和cpu曲线保持一致，此时我们可断定cpu飙升必然存在qps过高的原因
为了验证是否有慢sql的存在，再查看慢sql曲线：发现此案例中完全不存在慢sql
因此责任可100%归为qps过高，如果我们对该库所在实例开通的sql审计的功能，我们可查看过去一个月的qps记录，判断是由哪台机器发出的高频请求，以及请求的Top调用量的sql
如果我们没开通sql审计功能的话，阿里云也可查看当前对库的实时请求记录，或者我们可以以root用户登陆数据库，执行‘SHOW PROCESSLIST’命令查看
最后 定位了具体sql或者接口后 就可以针对性的解决问题：降级或者限流
定位是否为慢sql原因案例1 CPU峰刺例如以下案例：首先，查看当前cpu和qps曲线：从上图我们可看出，cpu和qps的整体的整体走势是基本一致的，但是上图中相对qps曲线，cpu有好几次的抖动，甚至峰值达到80%，我们需要排查出这些峰刺点
由于此时的cpu抖动和qps曲线不一致，可推测是慢sql引起的，观察下图抖动时间段内的慢sql，确定是否有慢sql，以及慢sql的具体信息
观察上图发现该时间段内一些慢sql在库上使得cpu曲线发生了抖动，此时可采取kill+id的方法定制该sql的执行
案例2 CPU明显飙升有时，我们会发现cpu和qps的曲线不够吻合，此时我们有较大的把握推测出原因就是慢sql引起的
如以下情况：红框内的cpu使用率在上升，但qps却在下降，观察以下慢sql监听：说明这段时间内的异常是100%是由慢sql引起的，可采取kill+id的方法定制该sql的执行
4 总结4.1 慢sql优化思路慢sql的优化思路较多，本文不打算赘述，仅提供以下几个方面优化思路
1.扫描数据库记录数较多
考虑表是否设置了合理的索引，表字段是否设置了合理的数据类型，sql是否有效的利用了索引等
2.sql中是否有做了大量的聚合、计算？考虑将sql简化，把逻辑操作上浮到业务中去做
3.sql返回的记录数过多
考虑分页实现，通过limit将一次请求转为多次请求
4.表中是否冗余字段过多？ 表若为宽表，包含大量冗余字段，可考虑分表
5.库中是否有很多张表？ 此时可考虑将表拆分到多个库中，分库
6.若库的读写较多，锁争抢激励，甚至死锁
可考虑多库做读写分离
7.机器的本身性能较低，不符合业务需求
可考虑机器升级了
4.2 qps过高优化思路
1.qps过高时，考虑是否可以使用缓存
2.使用批量操作，将多个操作合并为一次请求，但此种方式需要考虑是否可以一次批量的数据有多大，避免造成慢sql
3.考虑分库、读写分离，减少对一个机器的访问压力
4.机器升级，没什么是钱解决不了的
关注作者：JAVA高级程序员我会不定期在微头条发放：（Java工程化、分布式架构、高并发、高性能、深入浅出、微服务架构、Spring、MyBatis、Netty、源码分析）等技术学习资料，以及Java进阶学习路线图