惊了：《记一次数据库CPU使用率100%排查》
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进阶学习路线图。