百因必有果，你的报应就是我！

早上醒来发现钉钉群20+报警，异常奇怪，具体看看吧，是cpu过高，相信很多小伙伴也遇到过自己数据

库cpu大于80甚至100的时候，究竟是为什么呢？来自一java dev的笔记

Why

Case 1—> 慢sql

大多数的cpu过高都是由慢sql导致的，尤其是涉及到计算函数之类的，例如全表扫描或者说数据量过大，
内存排序 && 磁盘排序 以及 锁竞争等待…

那我们看到的又是什么呢？

以下截图来自百度~

此时CPU上升

QPS趋于稳定甚至有下降趋势

这类问题归功于慢sql导致的，可采取kill+id的方法先杀掉

我们通过 show processlist 可以看到当前正在执行的sql状态为

Sending data，Copying to tmp table，Copying to tmp table on disk，Sorting result，Using filesort，Locked;

Noted: 上述命令（show processlist）只能看到当前执行的sql对应进程，大半夜的又该怎么办呢？RDS

还是非常友好的，左侧菜单栏可以配置慢sql报警，对应的慢sql，连接的user等信息可以尽收眼底，回头

一一干掉，对了你也可以开通阿里云的sql审计功能，所有sql都会记录，但是！收费哈哈！

Case 2 —> QPS

观察CPU曲线利用率达到100

恰巧QPS对应的曲线利用率也是100

观察慢sql曲线，发现并不存在

总结：如遇以上情况，可以归功于QPS过高导致的，如有开通审计功能，可以查看最近一个月的QPS记录，找到对应的机器，对sql调用量进行top，如未开通，只好考虑对慢sql监控，进行报警，最终定位接口进行处理。

How

Case 1—> 慢sql

如果您的线上环境sql出现以上sql状态，说明sql性能有问题

Sending data： 正在执行sql查询，数据量过大或者说全表扫描了，没有建立索引，或者说索引建立

的不合适，索引失效等情况导致的sql查询时间过长。可以先看下该sql 执行计划 便后处理

Copying to tmp table on disk 像这种的状态一般都是sql查询的临时结果集过大，超过了数据库约

束的临时数据内存大小，需要将这个临时结果集拷贝到磁盘，无非就是sql查询范围过大或者sql查询时间

过长。

Sorting result，Using filesort： 对sql结果进行排序会产生高额的cpu消耗，多数情况下还是会借助

建立合适的索引消除排序或者减小排序结果集。

总而言之，言而总之，奇妙的事情诞生了，都是由于性能不高（慢sql）导致，处理线上慢sql，写好sql

是关键，sql优化老生常聊，大家也都知道，后续会为大家分享索引失效的篇章！

Case 2 —> QPS

A：可以考虑做缓存

B：多为一，将多个请求或者操作合成一个，谨慎！要考虑这一批数据量有多大，避免产生慢sql

C：做分库或者说读写分离，减轻单一服务器压力

D：花钱呗，升级服务器，没有啥是钱解决不了的